summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* lib/rsa: Use EVP_PKEY instead of RSAWIP/2021-04-14-assorted-vboot-improvementsChan, Donald2021-04-141-102/+67
| | | | | | | | | | Most modern OpenSSL engines have methods overridden at the EVP level rather than at RSA level, to make these engines work properly with mkimage, the RSA signing code needs to switch to using EVP_* APIs as much as possible. Signed-off-by: Donald Chan <hoiho@lab126.com> [trini: Rebase on top of keyfile changes] Signed-off-by: Tom Rini <trini@konsulko.com>
* image-fit: Accept OP-TEE images when booting a FITAlexandru Gagniuc2021-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | OP-TEE images are normally packaged with type = "tee; os = "tee"; However, fit_image_load() thinks that is somehow invalid. However if they were declared as type = "kernel", os = "linux", fit_image_load() would happily accept them and allow the boot to continue. There is no technical limitation to excluding "tee". Allowing "tee" images is useful in a boot flow where OP-TEE is executed before linux. In fact, I think it's unintuitive for a "load"ing function to also do parsing and contain a bunch ad-hoc heuristics that only its caller might know. But I don't make the rules, I just write fixes. In more polite terms: refactoring the fit_image API is beyond the scope of this change. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* image-fit: Accept IH_TYPE_FIRMWARE in fit_image_load() as validAlexandru Gagniuc2021-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | Consider the following FIT: images { whipple {}; }; configurations { conf-1 { firmware = "whipple"; }; }; Getting the 'firmware' image with fit_image_load() is not possible, as it doesn't understand 'firmware =' properties. Although one could pass IH_TYPE_FIRMWARE for 'image_type', this needs to be converted to a "firmware" string for FDT lookup -- exactly what this change does. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* spl: LOAD_FIT_FULL: Support 'kernel' and 'firmware' propertiesAlexandru Gagniuc2021-04-141-1/+18
| | | | | | | | The 'firmware' property of a config node takes precedence over the 'kernel' property. 'standalone' is deprecated. However, give users a couple of releases where 'standalone' still works, but warns loudly. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* spl: LOAD_FIT_FULL: Relocate FDT for u-boot payloadsAlexandru Gagniuc2021-04-141-1/+11
| | | | | | | | | | | | | | | | | U-Boot expects the FDT to be located right after the _end linker symbol (see fdtdec.c: board_fdt_blob_setup()) The "basic" LOAD_FIT path is aware of this limitation, and relocates the FDT at the expected location. Guessing the expected location probably only works reliably on 32-bit arm, and it feels like a hack. One proposal would be to pass the FDT address to u-boot (e.g. using 'r2' on arm platforms). The variable is named "fdt_hack" to remind future contributors that, "hey! we should fix the underlying problem". However, that is beyond the scope of this patch. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* spl: LOAD_FIT_FULL: Do not hard-code os to IH_OS_U_BOOTAlexandru Gagniuc2021-04-141-2/+3
| | | | | | | | | | The information on the OS should be contained in the FIT, as the self-explanatory "os" property of a node under /images. Hard-coding this to U_BOOT might send us down the wrong path later in the boot process. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* spl: LOAD_FIT_FULL: Fix selection of the "fdt" nodeAlexandru Gagniuc2021-04-141-3/+1
| | | | | | | | | | | | | | | | | | | The correct FDT to use is described by the "fdt" property of the configuration node. When the fit_unamep argument to fit_image_load() is "fdt", we get the "/images/fdt" node. This is incorrect, as it ignores the "fdt" property of the config node, and in most cases, the "/images/fdt" node doesn't exist. Use NULL for the 'fit_unamep' argument. With NULL, fit_image_load() uses the IH_TYPE_FLATDT value to read the config property "fdt", which points to the correct FDT node(s). fit_image_load() should probably be split into a function that reads an image by name, and one that reads an image by config reference. I don't make those decisions, I just point out the craziness. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* common: fit: Add weak board_fit_config_name_matchSean Anderson2021-04-143-19/+5
| | | | | | | | | | Several architectures had a default board_fit_config_name_match already; this provides a generic weak version. We default to rejecting all configs. This will use the FIT's default config, instead of the first config. This may result in boot failures if there are multiple configurations and the first config is *not* the default. Signed-off-by: Sean Anderson <sean.anderson@seco.com>
* doc: FIT image: Update FPGA example to make use of "loadables"Alexandru Gagniuc2021-04-141-1/+2
| | | | | | | | | | | The new correct way to load an FPGA image is to declare it in the list of "loadables". multi-with-fpga.its used the now deprecated "fpga" property. Since this example most likely intended to use u-boot's generic FPGA loading code, compatible = "u-boot,fpga-legacy" is also appropriate here. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* Kconfig: Document the limitations of the simple SPL_LOAD_FIT pathAlexandru Gagniuc2021-04-141-0/+10
| | | | | | | | | | | | | | The "simple" SPL_LOAD_FIT path is the most compliant with the format documented in doc/uImage.FIT/source_file_format.txt. The other two paths to load a FIT are SPL_LOAD_FIT_FULL and the "bootm" command. Since the Kconfig menu is the most likely place for a new user to see these options, it seems like the most logical candidate to document the limitations. This documents the _known_ issues, and is not intended to be a complete list of all follies. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* spl: fit: Support loading FPGA images from list of "loadables"Alexandru Gagniuc2021-04-141-0/+24
| | | | | | | | | | | | | Commit 4afc4f37c70e ("doc: FIT image: Clarify format and simplify syntax") and delegated FPGA images to be added via the list of "loadables" in lieu of the "fpga" property. Now actually implement this in code. Note that the "compatible" property is ignored for the time being, as implementing "compatible" loading is beyond the scope of this change. However, "u-boot,fpga-legacy" is accepted without warning. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* spl: fit: Warn if FIT contains "fpga" property in config nodeAlexandru Gagniuc2021-04-141-0/+8
| | | | | | | | | | | | | Commit 4afc4f37c70e ("doc: FIT image: Clarify format and simplify syntax") requires that FPGA images be referenced through the "loadables" in the config node. This means that "fpga" properties in config nodes are deprecated. Given that there are likely FIT images which use "fpga", let's not break those right away. Print a warning message that such use is deprecated, and give users a couple of releases to update their Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* spl: fit: Move FPGA loading code to separate functionsAlexandru Gagniuc2021-04-141-25/+45
| | | | | | | | | The FPGA loading code in spl_simple_fit_read() can easily be separated from the rest of the logic. It is split into two functions instead of one because spl_fit_upload_fpga() is used in a subsequent patch. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* doc: FIT image: Introduce "u-boot, fpga-legacy" propertyAlexandru Gagniuc2021-04-141-0/+1
| | | | | | | | | Commit 4afc4f37c70e ("doc: FIT image: Clarify format and simplify syntax") introduced a "compatible" property for loadable images. It did not define its contents. Use "u-boot,fpga-legacy" compatible string to specify that fpga_load() should be used to load the image. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
* spl: fit: Don't overwrite previous loadable if "load" is missingAlexandru Gagniuc2021-04-141-2/+9
| | | | | | | | | | | | | | | | | | | | | | | spl_load_fit_image() will try to load an image at the address given in the "load" property. Absent such property, it uses image_info->load_addr Correct use of this is demonstrated in spl_fit_append_fdt(), which resets the 'load_addr' before each spl_load_fit_image() call. On the other hand loading "loadables" loop in spl_load_simple_fit() completely ignores this. It re-uses the same structure, but doesn't reset load_addr. If loadable [i] does not have a "load" property, its load address defaults to load_addr, which still contains the address of loadable [i - 1]. A simple solution is to treat NULL as an invalid load address. The caller can set load_addr = 0 to request an abort if the "load" property is absent. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* test/py: ecdsa: Use mkimage keyfile instead of keydir argumentAlexandru Gagniuc2021-04-141-1/+1
| | | | | | | | | Originally, the ECDSA code path used 'keydir' as the key filename. mkimage has since been updated to include a new 'keyfile' argument. Use the new argument for passing in the key. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* lib/ecdsa: Use the 'keydir' argument from mkimage if appropriateAlexandru Gagniuc2021-04-141-1/+13
| | | | | | | | | Keys can be derived from keydir, and the "key-name-hint" property of the FIT. They can also be specified ad-literam via 'keyfile'. Update the ECDSA signing path to use the appropriate one. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* lib/rsa: Use the 'keyfile' argument from mkimageAlexandru Gagniuc2021-04-141-8/+26
| | | | | | | | | Keys can be derived from keydir, and the "key-name-hint" property of the FIT. They can also be specified ad-literam via 'keyfile'. Update the RSA signing path to use the appropriate one. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* mkimage: Add a 'keyfile' argument for image signingAlexandru Gagniuc2021-04-145-32/+52
| | | | | | | | | | | | It's not always desirable to use 'keydir' and some ad-hoc heuristics to get the filename of the signing key. More often, just passing the filename is the simpler, easier, and logical thing to do. Since mkimage doesn't use long options, we're slowly running out of letters. I've chosen '-G' because it was available. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* doc: signature.txt: Document the keydir and keyfile argumentsAlexandru Gagniuc2021-04-141-0/+13
| | | | | | | | After lots of debating, this documents how we'd like mkimage to treat 'keydir' and 'keyfile' arguments. The rest is in the docs. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* test/py: ecdsa: Add test for mkimage ECDSA signingAlexandru Gagniuc2021-04-141-0/+111
| | | | | | | | | | Add a test to make sure that the ECDSA signatures generated by mkimage can be verified successfully. pyCryptodomex was chosen as the crypto library because it integrates much better with python code. Using openssl would have been unnecessarily painful. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* test/py: Add pycryptodomex to list of required pakagesAlexandru Gagniuc2021-04-141-0/+1
| | | | | | | | | We wish to use pycryptodomex to verify code paths involving ECDSA signatures. Add it to requirements.txt so that they get picked up automatically .gitlab and .azure tasks Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* doc: signature.txt: Document devicetree format for ECDSA keysAlexandru Gagniuc2021-04-141-1/+6
| | | | | Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* lib: Add support for ECDSA image signingAlexandru Gagniuc2021-04-145-2/+415
| | | | | | | | | | | | | mkimage supports rsa2048, and rsa4096 signatures. With newer silicon now supporting hardware-accelerated ECDSA, it makes sense to expand signing support to elliptic curves. Implement host-side ECDSA signing and verification with libcrypto. Device-side implementation of signature verification is beyond the scope of this patch. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* lib/rsa: Make fdt_add_bignum() available outside of RSA codeAlexandru Gagniuc2021-04-144-64/+105
| | | | | | | | | | | fdt_add_bignum() is useful for algorithms other than just RSA. To allow its use for ECDSA, move it to a common file under lib/. The new file is suffixed with '-libcrypto' because it has a direct dependency on openssl. This is due to the use of the "BIGNUM *" type. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* lib: Rename rsa-checksum.c to hash-checksum.cAlexandru Gagniuc2021-04-1410-8/+11
| | | | | | | | | | | rsa-checksum.c sontains the hash_calculate() implementations. Despite the "rsa-" file prefix, this function is useful for other algorithms. To prevent confusion, move this file to lib/, and rename it to hash-checksum.c, to give it a more "generic" feel. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* Merge https://source.denx.de/u-boot/custodians/u-boot-shTom Rini2021-04-135-4/+65
|\ | | | | | | - arm: mach-rmobile: Add CPU info support for RZ/G2
| * arm: mach-rmobile: Add CPU info support for RZ/G2Biju Das2021-04-135-4/+65
|/ | | | | | Add CPU info support for RZ/G2 SoC's. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
* Merge branch '2021-04-13-assorted-improvements'Tom Rini2021-04-1381-739/+2142
|\ | | | | | | | | - A large assortment of bug fixes, code cleanups and a few feature enhancements.
| * cmd: exit: Fix return valueWIP/2021-04-12-assorted-improvementsMarek Vasut2021-04-121-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case exit is called in a script without parameter, the command returns -2 ; in case exit is called with a numerical parameter, the command returns -2 and lower. This leads to the following problem: => setenv foo 'echo bar ; exit 1' ; run foo ; echo $? bar 0 => setenv foo 'echo bar ; exit 0' ; run foo ; echo $? bar 0 => setenv foo 'echo bar ; exit -2' ; run foo ; echo $? bar 0 That is, no matter what the 'exit' command argument is, the return value is always 0 and so it is not possible to use script return value in subsequent tests. Fix this and simplify the exit command such that if exit is called with no argument, the command returns 0, just like 'true' in cmd/test.c. In case the command is called with any argument that is positive integer, the argument is set as return value. => setenv foo 'echo bar ; exit 1' ; run foo ; echo $? bar 1 => setenv foo 'echo bar ; exit 0' ; run foo ; echo $? bar 0 => setenv foo 'echo bar ; exit -2' ; run foo ; echo $? bar 0 Note that this does change ABI established in 2004 , although it is unclear whether that ABI was originally OK or not. Fixes: c26e454dfc6 Signed-off-by: Marek Vasut <marex@denx.de> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: Tom Rini <trini@konsulko.com>
| * scmi: translate the resource only when livetree is not activatedPatrick Delaunay2021-04-121-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call the translation function on the ofnode_read_resource result only when the livetree is not activated. Today of_address_to_resource() calls ofnode_read_resource() for livetree support and fdt_get_resource() when livetree is not supported. The fdt_get_resource() doesn't do the address translation so when it is required when livetree is activated but this address translation is already done by ofnode_read_resource(). Fixes: 240720e9052f ("firmware: scmi: mailbox/smt agent device") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * gpio: Drop dm_gpio_set_dir()Simon Glass2021-04-122-22/+0
| | | | | | | | | | | | | | This function is not used. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * gpio: i2c-gpio: Drop use of dm_gpio_set_dir()Simon Glass2021-04-121-10/+9
| | | | | | | | | | | | | | | | This is the only driver that uses this function. Update it to use the alternative which is dm_gpio_clrset_flags(). Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Harm Berntsen <harm.berntsen@nedap.com>
| * qemu: arm: select QFW, MMIO on qemu-armAsherah Connor2021-04-121-0/+2
| | | | | | | | | | | | | | | | | | Select CMD_QFW and QFW_MMIO in the qemu-arm board (covers arm and arm64). Signed-off-by: Asherah Connor <ashe@kivikakk.ee> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * qemu: add MMIO driver for QFWAsherah Connor2021-04-123-0/+127
| | | | | | | | | | | | | | | | | | | | Add MMIO driver for QFW. Note that there is no consumer as of this patch. Signed-off-by: Asherah Connor <ashe@kivikakk.ee> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * test: qemu: add qfw sandbox driver, dm tests, qemu testsAsherah Connor2021-04-127-2/+197
| | | | | | | | | | | | | | | | | | | | A sandbox driver and test are added for the qfw uclass, and a test in QEMU added for qfw functionality to confirm it doesn't break in real world use. Signed-off-by: Asherah Connor <ashe@kivikakk.ee> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: qemu: move QFW to its own uclassAsherah Connor2021-04-1213-272/+489
| | | | | | | | | | | | | | | | | | | | | | | | | | We move qfw into its own uclass and split the PIO functions into a specific driver for that uclass. The PIO driver is selected in the qemu-x86 board config (this covers x86 and x86_64). include/qfw.h is cleaned up and documentation added. Signed-off-by: Asherah Connor <ashe@kivikakk.ee> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * scmi: correctly configure MMU for SCMI bufferPatrick Delaunay2021-04-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Align the MMU area for SCMI shared buffer on section size; use the ALIGN macro in mmu_set_region_dcache_behaviour call. Since commit d877f8fd0f09 ("arm: provide a function for boards init code to modify MMU virtual-physical map") the parameter of mmu_set_region_dcache_behaviour need to be MMU_SECTION_SIZE aligned. Fixes: 240720e9052f ("firmware: scmi: mailbox/smt agent device") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
| * moveconfig.py: add to the "do not process" listTrevor Woerner2021-04-121-1/+1
| | | | | | | | | | | | | | Skip the processing of *.aml and *.dat files while iterating through the source in order to process header files. Signed-off-by: Trevor Woerner <twoerner@gmail.com>
| * checkpatch: Add warnings for using strn(cat|cpy)Sean Anderson2021-04-122-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | strn(cat|cpy) has a bad habit of not nul-terminating the destination, resulting in constructions like strncpy(foo, bar, sizeof(foo) - 1); foo[sizeof(foo) - 1] = '\0'; However, it is very easy to forget about this behavior and accidentally leave a string unterminated. This has shown up in some recent coverity scans [1, 2] (including code recently touched by yours truly). Fortunately, the guys at OpenBSD came up with strl(cat|cpy), which always nul-terminate strings. These functions are already in U-Boot, so we should encourage new code to use them instead of strn(cat|cpy). [1] https://lists.denx.de/pipermail/u-boot/2021-March/442888.html [2] https://lists.denx.de/pipermail/u-boot/2021-January/438073.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * fastboot: Fix possible buffer overrunSean Anderson2021-04-121-3/+3
| | | | | | | | | | | | | | | | | | | | This fixes several uses of strn(cpy|cat) which did not terminate their destinations properly. Fixes de1728ce4c ("fastboot: Allow u-boot-style partitions") Reported-by: Coverity Scan Signed-off-by: Sean Anderson <seanga2@gmail.com>
| * test: Add test for strlcatSean Anderson2021-04-122-0/+127
| | | | | | | | | | | | | | | | This test is adapted from glibc, which is very concerned about alignment. It also tests strlcpy by dependency. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * lib: string: Implement strlcatSean Anderson2021-04-123-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | This introduces strlcat, which provides a safer interface than strncat. It never copies more than its size bytes, including the terminating nul. In addition, it never reads past dest[size - 1], even if dest is not nul-terminated. This also removes the stub for dwc3 now that we have a proper implementation. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * lib: string: Fix strlcpy return valueSean Anderson2021-04-121-4/+8
| | | | | | | | | | | | | | | | | | | | strlcpy should always return the number of bytes copied. We were accidentally missing the nul-terminator. We also always used to return a non-zero value, even if we did not actually copy anything. Fixes: 23cd138503 ("Integrate USB gadget layer and USB CDC driver layer") Signed-off-by: Sean Anderson <seanga2@gmail.com>
| * tee: optee: Change printing during optee_probeIlias Apalodimas2021-04-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Right now the error messages when optee has a version mismatch or shared memory is not configured are done with a debug(). That's not very convenient since you have to enable debugging to figure out what's going on, although this is an actual error. So let's switch the debug() -> dev_err() and report those explicitly. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * terminal: only serial_reinit_all if availableAsherah Connor2021-04-121-1/+3
| | | | | | | | | | | | | | | | serial_reinit_all() is only available if CONFIG_SERIAL is defined (i.e. !CONFIG_DM_SERIAL). Signed-off-by: Asherah Connor <ashe@kivikakk.ee> Reviewed-by: Simon Glass <sjg@chromium.org>
| * terminal: correct stdio_dev invocationsAsherah Connor2021-04-121-6/+6
| | | | | | | | | | | | | | | | stdio_dev methods have taken a pointer to themselves since 709ea543 (nearly 7 years ago). Signed-off-by: Asherah Connor <ashe@kivikakk.ee> Reviewed-by: Simon Glass <sjg@chromium.org>
| * rtc: add support for rv3028 rtcHeiko Schocher2021-04-123-0/+215
| | | | | | | | | | | | | | | | | | | | Add support for rtc3028 rtc from microcrystal. based on linux dirver: commit a38fd8748464: ("Linux 5.12-rc2") Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Stefan Roese <sr@denx.de>
| * test: scmi: add local variables for scmi agent referenceEtienne Carriere2021-04-121-45/+55
| | | | | | | | | | | | | | | | | | | | | | Add local variables agent0/agent1 to refer to SCMI sandbox context agent and ease readability of the test. For consistency, rename regul_dev to regul0_dev and remove sandbox_voltd in dm_test_scmi_voltage_domains(). Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
| * firmware: scmi: fix inline comments and minor coding style issuesEtienne Carriere2021-04-123-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | Fix inline comments and empty line in scmi driver and test files. Remove test on IS_ENABLED(CONFIG_*_SCMI) in test/dm/scmi.c since these configuration are expected enabled when CONFIG_FIRMWARE_SCMI is enabled in sandbox configuration. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
View Lorry Controller Status