aboutsummaryrefslogtreecommitdiff
path: root/src/mainboard/dell/optiplex_9010/sch5545_ec.c
AgeCommit message (Collapse)Author
2020-12-02cbfs: Simplify load/map API names, remove type argumentsJulius Werner
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file() to cbfs_map() and cbfs_load() respectively. This is supposed to be the start of a new, better organized CBFS API where the most common operations have the most simple and straight-forward names. Less commonly used variants of these operations (e.g. cbfs_ro_load() or cbfs_region_load()) can be introduced later. It seems unnecessary to keep carrying around "boot" in the names of most CBFS APIs if the vast majority of accesses go to the boot CBFS (instead, more unusual operations should have longer names that describe how they diverge from the common ones). cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly reap mappings when desired. A few new cbfs_unmap() calls are added to generic code where it makes sense, but it seems unnecessary to introduce this everywhere in platform or architecture specific code where the boot medium is known to be memory-mapped anyway. In fact, even for non-memory-mapped platforms, sometimes leaking a mapping to the CBFS cache is a much cleaner solution than jumping through hoops to provide some other storage for some long-lived file object, and it shouldn't be outright forbidden when it makes sense. Additionally, remove the type arguments from these function signatures. The goal is to eventually remove type arguments for lookup from the whole CBFS API. Filenames already uniquely identify CBFS files. The type field is just informational, and there should be APIs to allow callers to check it when desired, but it's not clear what we gain from forcing this as a parameter into every single CBFS access when the vast majority of the time it provides no additional value and is just clutter. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-10-26src: Include <arch/io.h> when appropriateElyes HAOUAS
Change-Id: I4077b9dfeeb2a9126c35bbdd3d14c52e55a5e87c Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45404 Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-09-23mb/dell: Fix uninitialized variables usageJohn Zhao
Coverity detects uninitialized variables through PASS_BY_REFERENCE usage. Fix this issue by initializing variables before their uage. Found-by: Coverity CID 1429765, 1429772, 1429780 TEST=None Signed-off-by: John Zhao <john.zhao@intel.com> Change-Id: Ie583b072a76949fb3f17c1271a6427ee942db0ce Reviewed-on: https://review.coreboot.org/c/coreboot/+/45611 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
2020-09-21mb/dell: Drop unneeded empty linesElyes HAOUAS
Change-Id: I3d0ca401cf5268962bcd9074f94c37724cc0a836 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45250 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
2020-07-14src: Remove unused 'include <string.h>'Elyes HAOUAS
Found using: diff <(git grep -l '#include <string.h>' -- src/) <(git grep -l 'STRINGIFY\|memcpy\|memmove\|memset\|memcmp\|memchr\|strdup\|strconcat\|strnlen\|strlen\|strchr\|strncpy\|strcpy\|strcmp\|strncmp\|strspn\|strcspn\|strtok_r\|strtok\|atol\|strrchr\|skip_atoi\|snprintf' -- src/) |grep -v vendorcode |grep '<' Change-Id: I12802d0a6254b2fa39d59f485008bb2012f7b32d Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41913 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-16mb/dell/optiplex_9010: Add Dell OptiPlex 9010 SFF supportMichał Żygowski
Based on the autoport. The OptiPlex 9010 comes in four different sizes: MT, DT, SFF and USFF. Tested on SFF only. The other PCBs are slightly different, but they are designed with intercompatibility in mind. With small devicetree overrides it should work on OptiPlex 7010 and other OptiPlex 9010 variants as well. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Change-Id: I88d65cae30d08ca727d86d930707c2be25a527cf Reviewed-on: https://review.coreboot.org/c/coreboot/+/40351 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>