Get rid of some crufty macros.

These were macros that were never used, or that were only set to one thing and
could be substituted up front.

I left in code guarded by the HAVE_ENDIAN_H and HAVE_LITTLE_ENDIAN macros even
though those are never defined because they guard a reportedly significantly
faster implementation of some functionality, at least according to a comment
in the source. It would be a good idea to enable that code path and see if it
really does make a big difference before removing it entirely.

BUG=None
TEST=Built for Link, Daisy, and the host with FEATURES=test. Built depthcharge
for Link and booted in normal mode.
BRANCH=None

Change-Id: I934a4dd0da169ac018ba07350d56924ab88b1acc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/45687
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This commit is contained in:
Gabe Black
2013-03-16 04:03:40 -07:00
committed by ChromeBot
parent 77f55ca1cd
commit ac8805e7e9
43 changed files with 57 additions and 199 deletions

View File

@@ -140,9 +140,6 @@ int WriteAndFreeGptData(VbExDiskHandle_t disk_handle, GptData *gptdata)
return 0;
}
/* disable MSVC warning on const logical expression (as in } while(0);) */
__pragma(warning(disable: 4127))
VbError_t LoadKernel(LoadKernelParams *params)
{
VbSharedDataHeader *shared =
@@ -486,16 +483,13 @@ VbError_t LoadKernel(LoadKernelParams *params)
}
/* Read the kernel data */
VBPERFSTART("VB_RKD");
if (0 != VbExDiskRead(params->disk_handle,
part_start + body_offset_sectors,
body_sectors, params->kernel_buffer)) {
VBDEBUG(("Unable to read kernel data.\n"));
VBPERFEND("VB_RKD");
shpart->check_result = VBSD_LKP_CHECK_READ_DATA;
goto bad_kernel;
}
VBPERFEND("VB_RKD");
/* Verify kernel data */
if (0 != VerifyData((const uint8_t *)params->kernel_buffer,