summaryrefslogtreecommitdiff
path: root/src/device
AgeCommit message (Collapse)Author
2020-07-21device/cardbus_device.c: Drop `cardbus_size_bridge_resource`Angel Pons
It does nothing useful anymore. Drop it before it grows moss. Change-Id: I5f95376fe2a38eda5d819c53edb85ef11ab7a0f1 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43591 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-12device/xhci: Add helper method to iterate over xhci_supported_protoclRaul E Rangel
There is some boilerplate required to iterate over the USB supported protocol structs. Encapsulate all the in a method to make the callers simpler. BUG=b:154756391 TEST=Built test trembyle. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I401f10d242638b0000ba697573856d765333dca0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/43352 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-07-09device/pci_device.c: Drop dead codeAngel Pons
This code is not even being build-tested. Drop it before it grows moss. Change-Id: Id3f9dd264e82f93a438422e388d70e3f88ae0df9 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43210 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner
2020-06-19Kconfig: Escape variable to accommodate new Kconfig versionsPatrick Georgi
Kconfig 4.17 started using the $(..) syntax for environment variable expansion while we want to keep expansion to the build system. Older Kconfig versions (like ours) simply drop the escapes, not changing the behavior. While we could let Kconfig expand some of the variables, that only splits the handling in two places, making debugging harder and potentially messing with reproducible builds (e.g. when paths end up in configs), so escape them all. Change-Id: Ibc4087fdd76089352bd8dd0edb1351ec79ea4faa Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42481 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
2020-06-18src/device/Kconfig: Introduce WANT_LINEAR_FRAMEBUFFERAngel Pons
This decouples the linear framebuffer type from the symbols needing it. Change-Id: I733e630e0aa2fb2947d079caef26253ce443fe91 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42432 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-17treewide: Replace CONFIG(ARCH_xx) testsKyösti Mälkki
Once we support building stages for different architectures, such CONFIG(ARCH_xx) tests do not evaluate correctly anymore. Change-Id: I599995b3ed5c4dfd578c87067fe8bfc8c75b9d43 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42183 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-10device/xhci: Add xHCI utility to enumerate capabilitiesRaul E Rangel
This will allow enumerating an xHCI controller to allow dynamically generating the ACPI device nodes. BUG=b:154756391 TEST=Boot trembyle and see capabilities printed on console xHCI Supported Protocol: Major: 0x2, Minor: 0x0, Protocol: 'USB ' Port Offset: 1, Port Count: 2 xHCI Supported Protocol: Major: 0x3, Minor: 0x10, Protocol: 'USB ' Port Offset: 3, Port Count: 1 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I3065c3fffad01b5378a55cfe904f971079b13d0f Reviewed-on: https://review.coreboot.org/c/coreboot/+/41899 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-06-08device: Add a disabling PCIe device bus master functionJohn Zhao
A function pci_dev_disable_bus_master() is created. This function can be used to disable Thunderbolt PCIe root ports, bridges and devices for Vt-d based security platform at end of boot service. BUG=None TEST=Verified PCIe device bus master enable bit is cleared. Signed-off-by: John Zhao <john.zhao@intel.com> Change-Id: Ie92a15bf2c66fdc311098acb81019d4fb7f68313 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41042 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-06-06src: Use pci_dev_ops_pci where applicableAngel Pons
Change-Id: Ie004a94a49fc8f53c370412bee1c3e7eacbf8beb Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41944 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-06-02src: Remove redundant includesElyes HAOUAS
<types.h> is supposed to provide <commonlib/bsd/cb_err.h>, <stdbool.h>,<stdint.h> and <stddef.h>. So remove those includes each time when <types.h> is included. Change-Id: I886f02255099f3005852a2e6095b21ca86a940ed Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41817 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2020-05-28device/resource_allocator_v4: Improve the logging in resource allocatorFurquan Shaikh
This change makes the following improvements to debug logging in resource allocator: 1. Print depth is added to functions in pass 1 to better represent how the resource requirements of child devices impact the resource windows for parent bridge. 2. Device path is added to resource ranges to make it easier to understand what device the resouce ranges are associated with. 3. Prints in pass 2 (update constraints, resource ranges, resource assignment) are shifted left by 1 to make it easier to visualize resource allocation for each bridge including domain. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I3356a7278060e281d1a57d253537b097472827a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41478 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-28device/resource_allocator_v4: Change BIOS_SPEW to BIOS_DEBUGFurquan Shaikh
This change updates the log level for prints in resource allocator v4 to BIOS_DEBUG instead of BIOS_SPEW. These are critical in debugging issues and should be enabled at log level BIOS_DEBUG. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: Ib863619f5e1214e4fe6f05c52be6fa2de36e6c3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/41477 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-28Revert "Revert "pciexp_device: Add option to allocate prefetch memory above ↵Furquan Shaikh
4G boundary"" This reverts commit e15f352039a371156ceef37f0434003228166e99. Reason for revert: Resource allocator is split into old(v3) and new(v4). So, this change to provide an option to allocate prefetch memory above 4G boundary can be added back. Since the support for allocating above 4G boundary is available only in resource allocator v4, Kconfig option is accordingly updated to add depends on RESOURCE_ALLOCATOR_V4. Change-Id: I94e5866458c79c2719fd780f336fb5da71a7df66 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41467 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-28device: Enable resource allocation above 4G boundary with allocator v4Furquan Shaikh
This change adds back CB:39487 which was reverted as part of CB:41412. Now that the resource allocator is split into old(v3) and new(v4), this change adds support for allocating resources above 4G boundary with the new allocator v4. Original commit message: This change adds support for allocating resources above the 4G boundary by making use of memranges for resource windows enabled in the previous CL. It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the following ways: a) Downstream device resources can set this flag to indicate that they would like to have their resource allocation above the 4G boundary. These semantics will have to be enabled in the drivers managing the devices. It can also be extended to be enabled via devicetree. This flag is automatically propagated by the resource allocator from downstream devices to the upstream bridges in pass 1. It is done to ensure that the resource allocator has a global view of downstream requirements during pass 2 at domain level. b) Bridges have a single resource window for each of mem and prefmem resource types. Thus, if any downstream resource of the bridge requests allocation above 4G boundary, all the other downstream resources of the same type under the bridge will be allocated above 4G boundary. c) During pass 2, resource allocator at domain level splits IORESOURCE_MEM into two different memory ranges -- one for the window below 4G and other above 4G. Resource allocation happens separately for each of these windows. d) At the bridge level, there is no extra logic required since the resource will live entirely above or below the 4G boundary. Hence, all downstream devices of any bridge will fall within the window allocated to the bridge resource. To handle this case separately from that of domain, initializing of memranges for a bridge is done differently than the domain. Limitation: Resources of a given type at the bridge or downstream devices cannot live both above and below 4G boundary. Thus, if a bridge has some downstream resources requesting allocation for a given type above 4G boundary and other resources of the same type requesting allocation below 4G boundary, then all these resources of the same type get allocated above 4G boundary. Change-Id: I92a5cf7cd1457f2f713e1ffd8ea31796ce3d0cce Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41466 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-27resource_allocator_v4: Fix size of I/O hole at 0x3b0Furquan Shaikh
Addressing comment from CB:41443 that was received after the change landed. memranges_create_hole() takes size as the last parameter. So, the I/O hole created at 0x3b0 needs to set size as 0x3df - 0x3b0 + 1 as 0x3df is the upper limit of that hole. Change-Id: I08fca283436924427e12c6c69edced7e51db42a9 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41737 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-26device: Switch to resource allocator v4 by default treewideFurquan Shaikh
This change disables the old resource allocator by default and instead uses the new v4 resource allocator. Only the chipsets that explicitly select RESOURCE_ALLOCATOR_V3 will continue to use the old v3 resource allocator. Change-Id: I2ab9f1d612b5f193f058011a18b1d6373e09f788 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41445 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Mike Banon <mikebdp2@gmail.com>
2020-05-26device: Add support for resource allocator v4Furquan Shaikh
This change adds back support for the resource allocator using multiple ranges as originally landed in CB:39486(commit hash 3b02006) and reverted in CB:41413(commit hash 6186cbc). The new resource allocator can be selected by Kconfig option RESOURCE_ALLOCATOR_V4. It was identified that there are some AMD chipsets in the tree that do not really work well with the dynamic resource allocation. Until these chipsets are fixed, old (v3) and new (v4) of the resource allocator need to live side-by-side in the tree. There were some other chipsets in the tree which originally demonstrated problems with the new resource allocator, but have been since fixed in the tree. This change picks up the same additions as performed in CB:39486 along with the following changes: 1. Changes to avoid fixed resources in the entire tree. Use of search_bus_resources() is replaced with a walk of the entire tree in avoid_fixed_resources(). This is required to ensure that all fixed resources added to any device (including domain) are taken into consideration to avoid overlap during dynamic resource allocation. 2. Changes to set up alignment for memranges when initializing them. This is done to ensure that the right granularity is used for IORESOURCE_IO(no special alignment) and IORESOURCE_MEM(4KiB) resource requests. 3. mark_resource_invalid() is dropped as the resource no longer needs to be marked in any special way if allocation is not being done. Instead setting of IORESOURCE_ASSIGNED flag is skipped in this case. 4. initialize_memranges() is updated to check IORESOURCE_ASSIGNED instead of base == limit. Original commit message: This change updates the resource allocator in coreboot to allow using multiple ranges for resource allocation rather than restricting available window to a single base/limit pair. This is done in preparation to allow 64-bit resource allocation. Following changes are made as part of this: a) Resource allocator still makes 2 passes at the entire tree. The first pass is to gather the resource requirements of each device under each domain. It walks recursively in DFS fashion to gather the requirements of the leaf devices and propagates this back up to the downstream bridges of the domain. Domain is special in the sense that it has fixed resource ranges. Hence, the resource requirements from the downstream devices have no effect on the domain resource windows. This results in domain resource limits being unmodified after the first pass. b) Once the requirements for all the devices under the domain are gathered, resource allocator walks a second time to allocate resources to downstream devices as per the requirements. Here, instead of maintaining a single window for allocating resources, it creates a list of memranges starting with the resource window at domain and then applying constraints to create holes for any fixed resources. This ensures that there is no overlap with fixed resources under the domain. c) Domain does not differentiate between mem and prefmem. Since they are allocated space from the same resource window at the domain level, it considers all resource requests from downstream devices of the domain independent of the prefetch type. d) Once resource allocation is done at the domain level, resource allocator walks down the downstream bridges and continues the same process until it reaches the leaves. Bridges have separate windows for mem and prefmem. Hence, unlike domain, the resource allocator at bridge level ensures that downstream requirements are satisfied by taking prefetch type into consideration. e) This whole 2-pass process is performed for every domain in the system under the assumption that domains do not have overlapping address spaces. Noticeable differences from previous resource allocator: a) Changes in print logs observed due to flows being slightly different. b) Base, limit and size of domain resources are no longer updated based on downstream requirements. c) Memranges are used instead of a single base/limit pair for determining resource allocation. d) Previously, if a resource request did not fit in the available base/limit window, then the resource would be allocated over DRAM or any other address space defeating the principle of "no overlap". With this change, any time a resource cannot fit in the available ranges, it complains and ensures that the resource is effectively disabled by setting base same as the limit. e) Resource allocator no longer looks at multiple links to determine the right bus for a resource. None of the current boards have multiple buses under any downstream device of the domain. The only device with multiple links seems to be the cpu cluster device for some AMD platforms. Change-Id: Ide4d98528197bb03850a8fb4d73c41cd2c0195aa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41443 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-26device/resource_allocator_v3: Do not set IORESOURCE_ASSIGNED for size 0 resourceFurquan Shaikh
find_pci_tolm() is updated to ensure that it ignores resources that have a zero size. This change removes the setting of resource flags to IORESOURCE_ASSIGNED when the resource is not really allocated any space by the allocator. It also drops the setting of base to limit since that is not required anymore. Change-Id: If8c0d4bf1aa9cd6a5bdf056140f65cf2d70ed216 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41566 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-26device: Move resource allocation into a separate compilation unitFurquan Shaikh
This change moves the resource allocator functions out of device.c and into two separate files: 1. resource_allocator_v3.c: This is the old implementation of resource allocator that uses a single window for resource allocation. It is required to support some AMD chipsets that do not provide an accurate map of allocated resources by the time the allocator runs. They work fine with the old allocator since it restricts itself to allocations in a single window at the top of the 4G space. 2. resource_allocator_common.c: This file contains the functions that can be shared by the old and new resource allocator. Entry point into the resource allocation is allocate_resources() which can be implemented by both old and new allocators. This change also adds a Kconfig option RESOURCE_ALLOCATOR_V3 which enables the old resource allocator. This config option is enabled by default currently, but in the following CLs this will be enabled only for the broken boards. Reason for this split: Both the old and new resource allocators need to be retained in the tree until the broken chipsets are fixed. Change-Id: I2f5440cf83c6e9e15a5f22e79cc3c66aa2cec4c0 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41442 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-26device_util,agesa/family14: Do not consider unassigned resources in ↵Furquan Shaikh
find_pci_tolm() This change updates find_pci_tolm() to not consider any unassigned resources. This is achieved by adding the following checks: 1. Call search_bus_resources() with mask set to IORESOURCE_MEM | IORESOURCE_ASSIGNED. 2. In the callback tolm_test, check that the new resource selected has a non-zero size. This change is being made so that the resource allocator does not have to set the IORESOURCE_ASSIGNED flag for marking a resource as invalid. Change-Id: I796784dd93aa165e20a672c985b4875991901c87 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41524 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-05-26device/pci: Handle unassigned bus resources gracefullyNico Huber
The I/O windows of PCI bridges can be disabled individually by setting their limit lower than their base. Always do this if a resource wasn't assigned a value. Change-Id: I73f6817c4b12cb1689627044735d1fed6d825afe Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41552 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-26device/pci: Refactor pci_set_resource()Nico Huber
This function is too long and quirky. Factor the actual resource write out, so we can focus on the logic. Change-Id: I6c7f930614dcd63d4ee2a4ca7cf541a9de4fd557 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41551 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-26Remove MAYBE_STATIC_BSS and ENV_STAGE_HAS_BSS_SECTIONKyösti Mälkki
After removal of CAR_MIGRATION there are no more reasons to carry around ENV_STAGE_HAS_BSS_SECTION=n case. Replace 'MAYBE_STATIC_BSS' with 'static' and remove explicit zero-initializers. Change-Id: I14dd9f52da5b06f0116bd97496cf794e5e71bc37 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40535 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-20device/pci_device: Add notion of "hidden" PCI devicesTim Wawrzynczak
On some SoCs, there are PCI devices that may get hidden from PCI enumeration by platform firmware. Because the Vendor ID reads back as 0xffffffff, it appears that there is no PCI device located at that BDF. However, because the device does exist, designers may wish to hang its PCI resources off of a real __pci_driver, as well as have it participate in ACPI table generation. This patch extends the semantics of the 'hidden' keyword in devicetree.cb. If a device now uses 'hidden' instead of 'on', then it will be assumed during PCI enumeration that the device indeed does exist, and it will not be removed as a "leftover device." This allows child devices to be enumerated correctly and also PCI resources can be designated from the {read,set}_resources callbacks. It should be noted that as of this commit, there are precisely 0 devices using 'hidden' in their devicetree.cb files, so this should be a safe thing to do. Later patches will begin moving PCI resources from random places (typically hung off of fixed SA and LPC) into the PMC device (procedure will vary per- platform). Change-Id: I16c2d3e1d1433343e63dfc16856cff69cd815e2a Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41384 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-05-18device/pci_device: Remove useless pci_bus_ops_pciTim Wawrzynczak
The struct (formerly assigned to default_pci_ops_bus.ops_pci) only contained a NULL (well, 0) pointer for the set_subsystem callback, but usage of that callback is guarded with NULL checks when it is used, therefore it can be removed. TEST=still compiles Change-Id: I3943c8ae73b95e744a317264d7ceb8929cb28341 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41432 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-18src: Remove leading blank lines from SPDX headerElyes HAOUAS
Change-Id: I8a207e30a73d10fe67c0474ff11324ae99e2cec6 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41360 Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-16Revert "device: Enable resource allocator to use multiple ranges"Furquan Shaikh
This reverts commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7. Reason for revert: Resource allocator patches need to be reverted until the AMD chipsets can be fixed to handle the resource allocation flow correctly. BUG=b:149186922 Change-Id: Id9872b90482319748b4f3ba2e0de2185d5c50667 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41413 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-16Revert "device: Enable resource allocation above 4G boundary"Furquan Shaikh
This reverts commit 44ae0eacb82259243bf844a3fe5ad24a7821e997. Reason for revert: Resource allocator patches need to be reverted until the AMD chipsets can be fixed to handle the resource allocation flow correctly. BUG=b:149186922 Change-Id: I90f3eac2d23b5f59ab356ae48ed94d14c7405774 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41412 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Mike Banon <mikebdp2@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-16Revert "pciexp_device: Add option to allocate prefetch memory above 4G boundary"Furquan Shaikh
This reverts commit dcbf6454b6d2d9b3627a14126ef20ed4b9c7d954. Reason for revert: Resource allocator patches need to be reverted until the AMD chipsets can be fixed to handle the resource allocation flow correctly. Change-Id: I58c9fff1a18ea1c9941e29c2c6e60e338c517c30 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41465 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Mike Banon <mikebdp2@gmail.com>
2020-05-12util/sconfig: Add LPC and ESPI busesRaul E Rangel
Picasso has an LPC and eSPI bridge on the same PCI DEVFN. They can both be active at the same time. This adds a way to specify which devices belong on which bus. i.e., device pci 14.3 on # - D14F3 bridge device espi 0 on chip ec/google/chromeec device pnp 0c09.0 on end end end device lpc 0 on end end BUG=b:154445472 TEST=Built trembyle and saw static.c contained the espi bus. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I0c2f40813c05680f72e5f30cbb13617e8f994841 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41099 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-12device/pci_device: Extract pci_domain_set_resources from SOCRaul E Rangel
pci_domain_set_resources is duplicated in all the SOCs. This change promotes the duplicated function. Picasso was adding it again in the northbridge patch. I decided to promote the function instead of duplicating it. BUG=b:147042464 TEST=Build and boot trembyle. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Iba9661ac2c3a1803783d5aa32404143c9144aea5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/41041 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-12pciexp_device: Add option to allocate prefetch memory above 4G boundaryFurquan Shaikh
This change adds a Kconfig option to request allocation of prefetch memory for hotplug devices above the 4G boundary. In order to select this option by default and still allow users to disable this if required, another option is added to request allocation of prefetch memory below 4G boundary which defaults to n but can be overriden by mainboards. Without this change, if the number of pciexp bridges supporting hot-plug is more than 4 or if the reserved prefetch memory size for hot-plug cases was increased, then the resource allocator would fail to satisfy the resource requirement below 4G boundary. BUG=b:149186922 TEST=Enabled resource allocation above 4G for prefetch memory on volteer and verified that it gets allocated above 4G boundary. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I061d935eef9fcda352230b03b5cf14e467924e50 Reviewed-on: https://review.coreboot.org/c/coreboot/+/39489 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-12pci_device: Extend PCI domain limit to 64-bitFurquan Shaikh
This change updates the resource limit for PCI domain to allow resource allocation above 4G boundary. The resource limit is set to the highest physical address for the CPU. BUG=b:149186922 Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: Idfcc9a390d309886ee2b7880b29502c740e6578e Reviewed-on: https://review.coreboot.org/c/coreboot/+/39488 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-12device: Enable resource allocation above 4G boundaryFurquan Shaikh
This change adds support for allocating resources above the 4G boundary by making use of memranges for resource windows enabled in the previous CL. It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the following ways: a) Downstream device resources can set this flag to indicate that they would like to have their resource allocation above the 4G boundary. These semantics will have to be enabled in the drivers managing the devices. It can also be extended to be enabled via devicetree. This flag is automatically propagated by the resource allocator from downstream devices to the upstream bridges in pass 1. It is done to ensure that the resource allocator has a global view of downstream requirements during pass 2 at domain level. b) Bridges have a single resource window for each of mem and prefmem resource types. Thus, if any downstream resource of the bridge requests allocation above 4G boundary, all the other downstream resources of the same type under the bridge will be allocated above 4G boundary. c) During pass 2, resource allocator at domain level splits IORESOURCE_MEM into two different memory ranges -- one for the window below 4G and other above 4G. Resource allocation happens separately for each of these windows. d) At the bridge level, there is no extra logic required since the resource will live entirely above or below the 4G boundary. Hence, all downstream devices of any bridge will fall within the window allocated to the bridge resource. To handle this case separately from that of domain, initializing of memranges for a bridge is done differently than the domain. Limitation: Resources of a given type at the bridge or downstream devices cannot live both above and below 4G boundary. Thus, if a bridge has some downstream resources requesting allocation for a given type above 4G boundary and other resources of the same type requesting allocation below 4G boundary, then all these resources of the same type get allocated above 4G boundary. BUG=b:149186922 TEST=Verified that resources get allocated above the 4G boundary correctly on volteer. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: I7fb2a75cc280a307300d29ddabaebfc49175548f Reviewed-on: https://review.coreboot.org/c/coreboot/+/39487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-05-12device: Enable resource allocator to use multiple rangesFurquan Shaikh
This change updates the resource allocator in coreboot to allow using multiple ranges for resource allocation rather than restricting available window to a single base/limit pair. This is done in preparation to allow 64-bit resource allocation. Following changes are made as part of this: a) Resource allocator still makes 2 passes at the entire tree. The first pass is to gather the resource requirements of each device under each domain. It walks recursively in DFS fashion to gather the requirements of the leaf devices and propagates this back up to the downstream bridges of the domain. Domain is special in the sense that it has fixed resource ranges. Hence, the resource requirements from the downstream devices have no effect on the domain resource windows. This results in domain resource limits being unmodified after the first pass. b) Once the requirements for all the devices under the domain are gathered, resource allocator walks a second time to allocate resources to downstream devices as per the requirements. Here, instead of maintaining a single window for allocating resources, it creates a list of memranges starting with the resource window at domain and then applying constraints to create holes for any fixed resources. This ensures that there is no overlap with fixed resources under the domain. c) Domain does not differentiate between mem and prefmem. Since they are allocated space from the same resource window at the domain level, it considers all resource requests from downstream devices of the domain independent of the prefetch type. d) Once resource allocation is done at the domain level, resource allocator walks down the downstream bridges and continues the same process until it reaches the leaves. Bridges have separate windows for mem and prefmem. Hence, unlike domain, the resource allocator at bridge level ensures that downstream requirements are satisfied by taking prefetch type into consideration. e) This whole 2-pass process is performed for every domain in the system under the assumption that domains do not have overlapping address spaces. Noticeable differences from previous resource allocator: a) Changes in print logs observed due to flows being slightly different. b) Base, limit and size of domain resources are no longer updated based on downstream requirements. c) Memranges are used instead of a single base/limit pair for determining resource allocation. d) Previously, if a resource request did not fit in the available base/limit window, then the resource would be allocated over DRAM or any other address space defeating the principle of "no overlap". With this change, any time a resource cannot fit in the available ranges, it complains and ensures that the resource is effectively disabled by setting base same as the limit. e) Resource allocator no longer looks at multiple links to determine the right bus for a resource. None of the current boards have multiple buses under any downstream device of the domain. The only device with multiple links seems to be the cpu cluster device for some AMD platforms. BUG=b:149186922 TEST=Verified that resource allocation looks correct based on addresses assigned on Volteer. Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: Ia1f089877c62e119c6a994a10809c9cc0050ec9a Reviewed-on: https://review.coreboot.org/c/coreboot/+/39486 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-11treewide: Remove "this file is part of" linesPatrick Georgi
Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. */") -# This file is part of a set of unofficial pre-commit hooks available -/* This file is part of coreboot */ -# This file is part of msrtool. -/* This file is part of msrtool. */ - * This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. */ - * This file is part of the coreboot project. - /* This file is part of the coreboot project. */ -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/* This file is part of the coreboot project */ -/* This file is part of the coreboot project. */ -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - * This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. */ -/* This file is part of the ectool project. */ - * This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. */ -## This file is part of the superiotool project. -/* This file is part of the superiotool project */ -/* This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-09src/: Replace GPL boilerplate with SPDX headersPatrick Georgi
Used commands: perl -i -p0e 's|\/\*[\s*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-only */|' $(cat filelist) perl -i -p0e 's|\/\*[\s*]*.*is[\s*]*free[\s*]*software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*either[\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License,[\s*]*or[\s*]*.at[\s*]*your[\s*]*option.[\s*]*any[\s*]*later[\s*]*version.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-or-later */|' $(cat filelist) perl -i -p0e 's|\/\*[\s*]*.*is[\s*#]*free[\s*#]*software[;:,][\s*#]*you[\s*#]*can[\s*#]*redistribute[\s*#]*it[\s*#]*and/or[\s*#]*modify[\s*#]*it[\s*#]*under[\s*#]*the[\s*#]*terms[\s*#]*of[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*as[\s*#]*published[\s*#]*by[\s*#]*the[\s*#]*Free[\s*#]*Software[\s*#]*Foundation[;:,][\s*#]*either[\s*#]*version[\s*#]*3[\s*#]*of[\s*#]*the[\s*#]*License[;:,][\s*#]*or[\s*#]*.at[\s*#]*your[\s*#]*option.[\s*#]*any[\s*#]*later[\s*#]*version.[\s*#]*This[\s*#]*program[\s*#]*is[\s*#]*distributed[\s*#]*in[\s*#]*the[\s*#]*hope[\s*#]*that[\s*#]*it[\s*#]*will[\s*#]*be[\s*#]*useful[;:,][\s*#]*but[\s*#]*WITHOUT[\s*#]*ANY[\s*#]*WARRANTY[;:,][\s*#]*without[\s*#]*even[\s*#]*the[\s*#]*implied[\s*#]*warranty[\s*#]*of[\s*#]*MERCHANTABILITY[\s*#]*or[\s*#]*FITNESS[\s*#]*FOR[\s*#]*A[\s*#]*PARTICULAR[\s*#]*PURPOSE.[\s*#]*See[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*for[\s*#]*more[\s*#]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-3.0-or-later */|' $(cat filelist) perl -i -p0e 's|(\#\#*)[\w]*.*is free software[:;][\#\s]*you[\#\s]*can[\#\s]*redistribute[\#\s]*it[\#\s]*and\/or[\#\s]*modify[\#\s]*it[\s\#]*under[\s \#]*the[\s\#]*terms[\s\#]*of[\s\#]*the[\s\#]*GNU[\s\#]*General[\s\#]*Public[\s\#]*License[\s\#]*as[\s\#]*published[\s\#]*by[\s\#]*the[\s\#]*Free[\s\#]*Software[\s\#]*Foundation[;,][\s\#]*version[\s\#]*2[\s\#]*of[\s\#]*the[\s\#]*License.*[\s\#]*This[\s\#]*program[\s\#]*is[\s\#]*distributed[\s\#]*in[\s\#]*the[\s\#]*hope[\s\#]*that[\s\#]*it[\s\#]*will[\#\s]*be[\#\s]*useful,[\#\s]*but[\#\s]*WITHOUT[\#\s]*ANY[\#\s]*WARRANTY;[\#\s]*without[\#\s]*even[\#\s]*the[\#\s]*implied[\#\s]*warranty[\#\s]*of[\#\s]*MERCHANTABILITY[\#\s]*or[\#\s]*FITNESS[\#\s]*FOR[\#\s]*A[\#\s]*PARTICULAR[\#\s]*PURPOSE.[\#\s]*See[\#\s]*the[\#\s]*GNU[\#\s]*General[\#\s]*Public[\#\s]*License[\#\s]*for[\#\s]*more[\#\s]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist) perl -i -p0e 's|(\#\#*)[\w*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist) Change-Id: Ia01908544f4b92a2e06ea621eca548e582728280 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41178 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-06treewide: replace GPLv2 long form headers with SPDX headerPatrick Georgi
This replaces GPLv2-or-later and GPLv2-only long form text with the short SPDX identifiers. Commands used: perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.*of.*the.*License.*or.*(at.*your.*option).*any.*later.*version.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-or-later */|s' $(cat filelist) perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist) perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation[.;,].+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist) perl -i -p0e 's|/\*[*\n\t ]*This software is licensed under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation,.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist) Change-Id: I7a746088a35633c11fc7ebe86006e96458a1abf8 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41066 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-05-06treewide: Move "is part of the coreboot project" line in its own commentPatrick Georgi
That makes it easier to identify "license only" headers (because they are now license only) Script line used for that: perl -i -p0e 's|/\*.*\n.*This file is part of the coreboot project.*\n.*\*|/* This file is part of the coreboot project. */\n/*|' # ...filelist... Change-Id: I2280b19972e37c36d8c67a67e0320296567fa4f6 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41065 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-02acpi: Move ACPI table support out of arch/x86 (3/5)Furquan Shaikh
This change moves all ACPI table support in coreboot currently living under arch/x86 into common code to make it architecture independent. ACPI table generation is not really tied to any architecture and hence it makes sense to move this to its own directory. In order to make it easier to review, this change is being split into multiple CLs. This is change 3/5 which basically is generated by running the following command: $ git grep -iIl "arch/acpi" | xargs sed -i 's/arch\/acpi/acpi\/acpi/g' BUG=b:155428745 Change-Id: I16b1c45d954d6440fb9db1d3710063a47b582eae Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40938 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-04-28device: Constify struct device * parameter to acpi_fill_ssdt()Furquan Shaikh
.acpi_fill_ssdt() does not need to modify the device structure. This change makes the struct device * parameter to acpi_fill_ssdt() as const. Change-Id: I110f4c67c3b6671c9ac0a82e02609902a8ee5d5c Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40710 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-28device: Constify struct device * parameter to dev_nameFurquan Shaikh
dev_name() does not need to modify the device structure. Hence, this change makes the struct device * parameter to dev_name() as const. Change-Id: I6a94394385e45fd76f68218bf57914bddd2e2121 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40703 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-28device: Constify struct device * parameter to write_acpi_tablesFurquan Shaikh
.write_acpi_tables() should not be updating the device structure. This change makes the struct device * argument to it as const. Change-Id: I50d013e83a404e0a0e3837ca16fa75c7eaa0e14a Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40701 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-04-22device: Add helper function to find matching device on busFurquan Shaikh
This change adds a helper function dev_find_matching_device_on_bus() which scans all the child devices on the given bus and calls a match function provided by the caller. It returns the first device that the match function returns true for, else NULL if no such device is found. Change-Id: I2e3332c0a175ab995c523f078f29a9f498f17931 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40543 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-22device: Add a helper to find device behind a PCI-to-PCI bridge deviceFurquan Shaikh
This change adds a helper function to find PCI device with dev# and function# behind a PCI-to-PCI bridge device. BUG=b:153858769 BRANCH=None TEST=None Signed-off-by: Furquan Shaikh <furquan@google.com> Change-Id: Ie5672b35cda66431a0f1977f217bdf61d3012ace Reviewed-on: https://review.coreboot.org/c/coreboot/+/40474 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-22device: Add checks for NULL in device_const.c functionsFurquan Shaikh
This change checks to ensure that device/path passed into any of the functions in device_const.c is not NULL. Since NULL is not expected to be passed into these functions, this change adds a die() call in case the assumption is broken. Change-Id: I1ad8d2bcb9d0546104c5e065af1eeff331cdf96d Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40475 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-04-20drivers/pc80/rtc: Reorganize prototypesKyösti Mälkki
Change-Id: Idea18f437c31ebe83dd61a185e614106a1f8f976 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38199 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-04-10Replace DEVICE_NOOP with noop_(set|read)_resourcesNico Huber
`.read_resources` and `.set_resources` are the only two device operations that are considered mandatory. Other function pointers can be left NULL. Having dedicated no-op implementations for the two mandatory fields should stop the leaking of no-op pointers to other fields. Change-Id: I6469a7568dc24317c95e238749d878e798b0a362 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40207 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-10Drop unnecessary DEVICE_NOOP entriesNico Huber
Providing an explicit no-op function pointer is only necessary for `.read_resources` and `.set_resources`. All other device-operation pointers are optional and can be NULL. Change-Id: I3d139f7be86180558cabec04b8566873062e33be Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40206 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-05Drop explicit NULL initializations from `device_operations`Elyes HAOUAS
Unmentioned fields are initialized with 0 (or NULL) implicitly. Beside that, the struct has grown over the years. There are too many optional fields to list them all. Change-Id: Icb9e14c58153d7c14817bcde148e86e977666e4b Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40126 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 16:52:28 +0000