aboutsummaryrefslogtreecommitdiff
path: root/common/command.c
diff options
context:
space:
mode:
authorSimon Glass <sjg@chromium.org>2019-07-08 14:25:35 -0600
committerSimon Glass <sjg@chromium.org>2019-07-24 12:54:08 -0700
commita0dcaf2049056348b8b603116ed1d8556851e951 (patch)
treebd705aace1869b281b8035382c77fa5c723361ff /common/command.c
parent7f9e00a2a6a3aff06572fdf225e51556f85853f4 (diff)
downloadu-boot-a0dcaf2049056348b8b603116ed1d8556851e951.zip
u-boot-a0dcaf2049056348b8b603116ed1d8556851e951.tar.gz
u-boot-a0dcaf2049056348b8b603116ed1d8556851e951.tar.bz2
binman: Add a return value to ProcessContentsUpdate()
At present if this function tries to update the contents such that the size changes, it raises an error. We plan to add the ability to change the size of entries after packing is completed, since in some cases it is not possible to determine the size in advance. An example of this is with a compressed device tree, where the values of the device tree change in SetCalculatedProperties() or ProcessEntryContents(). While the device tree itself does not change size, since placeholders for any new properties have already bee added by AddMissingProperties(), we cannot predict the size of the device tree after compression. If a value changes from 0 to 0x1234 (say), then the compressed device tree may expand. As a first step towards supporting this, make ProcessContentsUpdate() return a value indicating whether the content size is OK. For now this is always True (since otherwise binman raises an error), but later patches will adjust this. Signed-off-by: Simon Glass <sjg@chromium.org>
Diffstat (limited to 'common/command.c')
0 files changed, 0 insertions, 0 deletions