summaryrefslogtreecommitdiffstats
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Revert "lib: fdt: Split fdtdec_setup_mem_size_base()"Michal Simek2020-07-251-8/+3
| | | | | | | | | This reverts commit 3ebe09d09a407f93022d945a205c5318239eb3f6. There is no user of this split function that's why remove it. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* Revert "lib: fdt: Split fdtdec_setup_memory_banksize()"Michal Simek2020-07-251-12/+6
| | | | | | | | | This reverts commit 118f4d4559a4386fa87a1e2509e84a1986b24a34. There is no user of this split function that's why remove it. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* Revert "Merge tag 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm"Tom Rini2020-07-241-9/+20
| | | | | | | | | | This reverts commit 5d3a21df6694ebd66d5c34c9d62a26edc7456fc7, reversing changes made to 56d37f1c564107e27d873181d838571b7d7860e7. Unfortunately this is causing CI failures: https://travis-ci.org/github/trini/u-boot/jobs/711313649 Signed-off-by: Tom Rini <trini@konsulko.com>
* Merge tag 'dm-pull-20jul20' of git://git.denx.de/u-boot-dmTom Rini2020-07-231-20/+9
|\ | | | | | | | | | | | | | | binman support for FIT new UCLASS_SOC patman switch 'test' command minor fdt fixes patman usability improvements
| * Revert "lib: fdt: Split fdtdec_setup_mem_size_base()"Michal Simek2020-07-201-8/+3
| | | | | | | | | | | | | | | | | | This reverts commit 3ebe09d09a407f93022d945a205c5318239eb3f6. There is no user of this split function that's why remove it. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * Revert "lib: fdt: Split fdtdec_setup_memory_banksize()"Michal Simek2020-07-201-12/+6
| | | | | | | | | | | | | | | | | | This reverts commit 118f4d4559a4386fa87a1e2509e84a1986b24a34. There is no user of this split function that's why remove it. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* | lib: crypto: export and enhance pkcs7_verify_one()AKASHI Takahiro2020-07-221-7/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | The function, pkcs7_verify_one(), will be utilized to rework signature verification logic aiming to support intermediate certificates in "chain of trust." To do that, its function interface is expanded, adding an extra argument which is expected to return the last certificate in trusted chain. Then, this last one must further be verified with signature database, db and/or dbx. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
* | lib: crypto: add pkcs7_digest()AKASHI Takahiro2020-07-221-3/+89
| | | | | | | | | | | | | | | | | | | | | | This function was nullified when the file, pkcs7_verify.c, was imported because it calls further linux-specific interfaces inside, hence that could lead to more files being imported from linux. We need this function in pkcs7_verify_one() and so simply re-implement it here instead of re-using the code. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
* | lib: crypto: import pkcs7_verify.c from linuxAKASHI Takahiro2020-07-223-0/+528
| | | | | | | | | | | | | | | | | | | | | | | | The file, pkcs7_verify.c, will now be imported from linux code (crypto/asymmetric_keys/pkcs7_verify.c in 5.7) and modified to fit into U-Boot environment. In particular, pkcs7_verify_one() function will be used in a later patch to rework signature verification logic aiming to support intermediate certificates in "chain of trust." Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
* | lib: crypto: enable x509_check_for_self_signed()AKASHI Takahiro2020-07-222-10/+25
| | | | | | | | | | | | | | | | | | | | | | When the file, x509_public_key.c, was imported from linux code in commit b4adf627d5b7 ("lib: crypto: add x509 parser"), x509_check_for_self_signed() was commented out for simplicity. Now it need be enabled in order to make pkcs7_verify_one(), which will be imported in a later patch, functional. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
* | lib: crypto: add public_key_verify_signature()AKASHI Takahiro2020-07-221-1/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | This function will be called from x509_check_for_self_signed() and pkcs7_verify_one(), which will be imported from linux in a later patch. While it does exist in linux code and has a similar functionality of rsa_verify(), it calls further linux-specific interfaces inside. That could lead to more files being imported from linux. So simply re-implement it here instead of re-using the code. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
* | efi_loader: use logging for block device messagesHeinrich Schuchardt2020-07-221-10/+13
| | | | | | | | | | | | | | Use logging instead of printf() for messages occurring when scanning block devices during the initialization of the UEFI sub-system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* | efi_loader: document efi_save_gd(), efi_restore_gd()Heinrich Schuchardt2020-07-221-5/+15
| | | | | | | | | | | | Provide function descriptions for efi_save_gd() and efi_restore_gd(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* | efi_loader: loosen buffer parameter check in efi_file_readStefan Sørensen2020-07-221-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When reading a directory, EFI_BUFFER_TOO_SMALL should be returned when the supplied buffer is too small, so a use-case is to call efi_file_read with *buffer_size=0 and buffer=NULL to obtain the needed size before doing the actual read. So move the buffer!=NULL check to after the buffer size has been checked. This fix allows the Redhat shim fallback to run and e.g. Fedora 32 now boots out of the box. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* | efi_loader: Check for the native OP-TEE result on mm_communicate callsIlias Apalodimas2020-07-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we only check for the return value of tee_invoke_func(). Although OP-TEE and StMM will correctly set param[1].u.value.a and we'll eventually return an error, the correct thing to do is check for the OP_TEE return code as well. So let's check for that and move tee_shm_free() and tee_close_session() before exiting with an error to make sure we always clear the registered memory. Fixes: f042e47e8fb43 ("efi_loader: Implement EFI variable handling via OP-TEE") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Use EFI_DEVICE_ERROR for TEE communication problems. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* | efi_loader: Rename and correct values for ARM_SMC_MM_*Ilias Apalodimas2020-07-221-4/+4
| | | | | | | | | | | | | | | | | | | | | | Instead of adding the definition for the specific MM SVC used in StandAloneMM we added the one used in the standard SMC calls. So change the value from -4 to -5 to match the correct one defined in EDK2 and rename them to avoid future confusion Fixes 23a397d2e2fb: ("efi_loader: Add headers for EDK2 StandAloneMM communication") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* | efi_loader: don't use memmove() in efi_var_mem_del()Heinrich Schuchardt2020-07-222-1/+4
| | | | | | | | | | | | | | | | efi_var_mem_del() is in __efi_runtime because it would be needed for a runtime implementation of SetVariable(). memmove() is not in __efi_runtime. So we should not use it in efi_var_mem_del(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* | efi_loader: efi_current_var after SetVirtualAddressMapHeinrich Schuchardt2020-07-221-0/+1
|/ | | | | | | | | Variable efi_current_var is a pointer to a physical memory address that becomes invalid after SetVirtualAddressMap(). Instead of converting it via ConvertPointer() simply set it to NULL. Fixes: b02a707152dc ("efi_loader: enable UEFI variables at runtime") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* treewide: convert bd_t to struct bd_info by coccinelleMasahiro Yamada2020-07-172-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linux coding style guide (Documentation/process/coding-style.rst) clearly says: It's a **mistake** to use typedef for structures and pointers. Besides, using typedef for structures is annoying when you try to make headers self-contained. Let's say you have the following function declaration in a header: void foo(bd_t *bd); This is not self-contained since bd_t is not defined. To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h> #include <asm/u-boot.h> void foo(bd_t *bd); Then, the include direcective pulls in more bloat needlessly. If you use 'struct bd_info' instead, it is enough to put a forward declaration as follows: struct bd_info; void foo(struct bd_info *bd); Right, typedef'ing bd_t is a mistake. I used coccinelle to generate this commit. The semantic patch that makes this change is as follows: <smpl> @@ typedef bd_t; @@ -bd_t +struct bd_info </smpl> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* lib: zlib: Remove offset pointer optimization in inftrees.cChin Liang See2020-07-171-11/+8
| | | | | | | | | | | | | | | | | | | This fixes the CVE-2016-9840. Commit imported from [1]. inftrees.c was subtracting an offset from a pointer to an array, in order to provide a pointer that allowed indexing starting at the offset. This is not compliant with the C standard, for which the behavior of a pointer decremented before its allocated memory is undefined. Per the recommendation of a security audit of the zlib code by Trail of Bits and TrustInSoft, in support of the Mozilla Foundation, this tiny optimization was removed, in order to avoid the possibility of undefined behavior. [1]: https://github.com/madler/zlib/commit/6a043145ca6e9c55184013841a67b2fef87e44c0 Signed-off-by: Mark Adler <madler@alumni.caltech.edu> Signed-off-by: Chin Liang See <chin.liang.see@intel.com> Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
* lz4: fix decompressor on big-endian powerpcRasmus Villemoes2020-07-171-56/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Booting an lz4-compressed kernel image fails on our powerpc board with -EPROTONOSUPPORT. Adding a bit of debug prints, we get magic: 0x184d2204 flags: 0x64 reserved0: 1 has_content_checksum: 1 has_content_size: 0 has_block_checksum: 0 independent_blocks: 1 version: 0 block_descriptor: 70 reserved1: 7 max_block_size: 0 reserved2: 0 So the magic is ok, but the version check fails, also some reserved bits are apparently set. But that's because the code interprets the "flags" and "block_descriptor" bytes wrongly: Using bit-fields to access individual bits of an "on the wire" format is not portable, not even when restricted to the C flavour implemented by gcc. Quoting the gcc manual: * 'The order of allocation of bit-fields within a unit (C90 6.5.2.1, C99 and C11 6.7.2.1).' Determined by ABI. and indeed, the PPC Processor ABI supplement says * Bit-fields are allocated from right to left (least to most significant) on Little-Endian implementations and from left to right (most to least significant) on Big-Endian implementations. The upstream code (github.com/lz4/lz4) uses explicit shifts and masks for encoding/decoding: /* FLG Byte */ *dstPtr++ = (BYTE)(((1 & _2BITS) << 6) /* Version('01') */ + ((cctxPtr->prefs.frameInfo.blockMode & _1BIT ) << 5) + ((cctxPtr->prefs.frameInfo.blockChecksumFlag & _1BIT ) << 4) + ((unsigned)(cctxPtr->prefs.frameInfo.contentSize > 0) << 3) + ((cctxPtr->prefs.frameInfo.contentChecksumFlag & _1BIT ) << 2) + (cctxPtr->prefs.frameInfo.dictID > 0) ); /* Flags */ { U32 const FLG = srcPtr[4]; U32 const version = (FLG>>6) & _2BITS; blockChecksumFlag = (FLG>>4) & _1BIT; blockMode = (FLG>>5) & _1BIT; contentSizeFlag = (FLG>>3) & _1BIT; contentChecksumFlag = (FLG>>2) & _1BIT; dictIDFlag = FLG & _1BIT; /* validate */ if (((FLG>>1)&_1BIT) != 0) return err0r(LZ4F_ERROR_reservedFlag_set); /* Reserved bit */ if (version != 1) return err0r(LZ4F_ERROR_headerVersion_wrong); /* Version Number, only supported value */ } Do the same here, and while at it, be more careful to use unaligned accessors to what is most likely unaligned. Also update the comment to make it clear that it only refers to the lz4.c file, not the following code of lz4_wrapper.c. This has been tested partly, of course, by seeing that my lz4-compressed kernel now boots, partly by running the (de)compression test-suite in the (x86_64) sandbox - i.e., it should still work just fine on little-endian hosts. Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
* acpi: Support writing named valuesSimon Glass2020-07-171-0/+49
| | | | | | | | | | Allow writing named integers and strings to the generated ACPI code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> [bmeng: Fix the "new blank line at EOF" warning] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support generation of a deviceSimon Glass2020-07-171-0/+7
| | | | | | | | | | Allow writing an ACPI device to the generated ACPI code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> [bmeng: Fix build failures on Sandbox] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support generation of a generic registerSimon Glass2020-07-171-0/+71
| | | | | | | | | | Allow writing out a generic register. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> [bmeng: Fix build failures on Sandbox] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support generation of a scopeSimon Glass2020-07-171-0/+7
| | | | | | | | | | Add a function to write a scope to the generated ACPI code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: Fix build failures on Sandbox] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
* binman: Add way to locate an entry in memorySimon Glass2020-07-171-0/+23
| | | | | | | Add support for accessing an entry's contents in memory-mapped SPI flash. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* binman: Refactor binman_entry_find() to allow other nodesSimon Glass2020-07-171-6/+13
| | | | | | | | | At present we can only read from a top-level binman node entry. Refactor this function to produce a second local function which supports reading from any node. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* binman: Allow setting the ROM offsetSimon Glass2020-07-171-0/+17
| | | | | | | | On x86 the SPI ROM can be memory-mapped, at least most of it. Add a way to tell binman the offset from a ROM address to a RAM address. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* dm: acpi: Enhance acpi_get_name()Simon Glass2020-07-171-0/+106
| | | | | | | | | | | | | | | | | | | For many device types it is possible to figure out the name just by looking at its uclass or parent. Add a function to handle this, since it allows us to cover the vast majority of cases automatically. However it is sometimes impossible to figure out an ACPI name for a device just by looking at its uclass. For example a touch device may have a vendor-specific name. Add a new "acpi,name" property to allow a custom name to be created. With this new feature we can drop the get_name() methods in the sandbox I2C and SPI drivers. They were only added for testing purposes. Update the tests to use the new values. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Add support for a generic power sequenceSimon Glass2020-07-171-0/+99
| | | | | | | | | | Add a way for devices to enable and disable themselves using ACPI code that updates GPIOs. This takes several timing parameters and supports enable, reset and stop. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Add support for writing a GPIO power sequenceSimon Glass2020-07-171-0/+85
| | | | | | | | | | Power to some devices is controlled by GPIOs. Add a way to generate ACPI code to enable and disable a GPIO so that this can be handled within an ACPI method. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Add support for writing a Power ResourceSimon Glass2020-07-171-0/+22
| | | | | | | | | | These are used in ACPI to disable power to various pats of the system when in sleep. Add a way to create a power resource, with the caller finishing off the details. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Add support for various misc ACPI opcodesSimon Glass2020-07-171-0/+86
| | | | | | | | Add more functions to handle some miscellaneous ACPI opcodes. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support copying properties from device tree to ACPISimon Glass2020-07-171-0/+56
| | | | | | | | | | | | | Some drivers in Linux support both device tree and ACPI. U-Boot itself uses Linux device-tree bindings for its own configuration but does not use ACPI. It is convenient to copy these values over to the ACPI DP table for passing to linux. Add some convenience functions to help with this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support writing a GPIOSimon Glass2020-07-171-0/+23
| | | | | | | | | Allowing writing out a reference to a GPIO within the ACPI output. This can be used by ACPI code to access a GPIO at runtime. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support writing Device Properties objects via _DSDSimon Glass2020-07-172-0/+324
| | | | | | | | | | | | | | More complex device properties can be provided to drivers via a device-specific data (_DSD) object. To create this we need to build it up in a separate data structure and then generate the ACPI code, due to its recursive nature. Add an implementation of this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support writing a UUIDSimon Glass2020-07-171-0/+38
| | | | | | | | | ACPI supports writing a UUID in a special format. Add a function to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support writing a nameSimon Glass2020-07-171-0/+96
| | | | | | | | | ACPI supports storing names which are made up of multiple path components. Several special cases are supported. Add a function to emit a name. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support writing a stringSimon Glass2020-07-171-0/+6
| | | | | | | | | ACPI supports storing a simple null-terminated string. Add support for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support writing an integerSimon Glass2020-07-171-0/+51
| | | | | | | | | ACPI supports storing integers in various ways. Add a function to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpigen: Support writing a packageSimon Glass2020-07-171-0/+12
| | | | | | | | | A package collects together several elements. Add an easy way of writing a package header and updating its length later. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpigen: Support writing a lengthSimon Glass2020-07-171-0/+33
| | | | | | | | | | | It is convenient to write a length value for preceding a block of data. Of course the length is not known or is hard to calculate a priori. So add a way to mark the start on a stack, so the length can be updated when known. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support generation of SPI descriptorSimon Glass2020-07-171-0/+124
| | | | | | | | Add a function to write a SPI descriptor to the generated ACPI code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support generation of I2C descriptorSimon Glass2020-07-171-0/+107
| | | | | | | | Add a function to write a GPIO descriptor to the generated ACPI code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support generation of a GPIO/irq for a deviceSimon Glass2020-07-171-1/+30
| | | | | | | | | | | | Some devices use interrupts but some use GPIOs. Since these are fully specified in the device tree we can automatically produce the correct ACPI descriptor for a device. Add a function to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support generation of GPIO descriptorSimon Glass2020-07-171-0/+151
| | | | | | | | | | Add a function to write a GPIO descriptor to the generated ACPI code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [bmeng: Drop comment about the type always being ACPI_GPIO_TYPE_IO] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support string outputSimon Glass2020-07-171-0/+14
| | | | | | | | Add support for output of strings and streams of bytes. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support generation of interrupt descriptorSimon Glass2020-07-171-0/+119
| | | | | | | | | Add a function to write an interrupt descriptor to the generated ACPI code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Support generation of ACPI codeSimon Glass2020-07-173-0/+41
| | | | | | | | | | | | | | Add a new file to handle generating ACPI code programatically. This is used when information must be dynamically added to the tables, e.g. the SSDT. Initial support is just for writing simple values. Also add a 'base' value so that the table can be freed. This likely doesn't happen in normal code, but is nice to do in tests. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* acpi: Add a way to check device statusSimon Glass2020-07-171-0/+5
| | | | | | | | | | At present U-Boot does not support the different ACPI status values, but it is best to put this logic in a central place. Add a function to get the device status. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
generated by cgit (git 2.34.1) at 2024-06-28 05:32:56 +0000