History log of /u-boot/lib/abuf.c
Revision Date Author Comments
# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 467382ca 14-Dec-2023 Tom Rini <trini@konsulko.com>

lib: Remove <common.h> inclusion from these files

After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

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


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

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


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

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


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

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


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 34ecba1f 14-Aug-2023 Simon Glass <sjg@chromium.org>

abuf: Allow incrementing the size

Provide a convenience function to increment the size of the abuf.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 90ad4e28 15-Jan-2023 Simon Glass <sjg@chromium.org>

abuf: Support use from tools

Update the code slightly so that abuf can be used in U-Boot tools. It will
soon be needed for proftool.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 99aca9ef 28-Feb-2022 Simon Glass <sjg@chromium.org>

abuf: Correct a corner case with abuf_realloc()

If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>


# 67bc59df 25-Sep-2021 Simon Glass <sjg@chromium.org>

Add support for an owned buffer

When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.

Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.

Introduce a new 'abuf' which supports simple buffer operations:

- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed

This simple API makes it easier to deal with allocated and memory-mapped
buffers.

Signed-off-by: Simon Glass <sjg@chromium.org>