summaryrefslogtreecommitdiff
path: root/doc/api
AgeCommit message (Collapse)AuthorFilesLines
2022-10-06doc: documentation of EFI driver binding protocolHeinrich Schuchardt1-0/+6
* Convert code comments in include/efi_driver.h to Sphinx style. * Add include/efi_driver.h to the HTML documentation. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2022-06-23linker_lists: Rename sections to remove . prefixAndrew Scull1-11/+11
Rename the sections used to implement linker lists so they begin with '__u_boot_list' rather than '.u_boot_list'. The double underscore at the start is still distinct from the single underscore used by the symbol names. Having a '.' in the section names conflicts with clang's ASAN instrumentation which tries to add redzones between the linker list elements, causing expected accesses to fail. However, clang doesn't try to add redzones to user sections, which are names with all alphanumeric and underscore characters. Signed-off-by: Andrew Scull <ascull@google.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-06-08misc: Add support for nvmem cellsSean Anderson2-0/+11
This adds support for "nvmem cells" as seen in Linux. The nvmem device class in Linux is used for various assorted ROMs and EEPROMs. In this sense, it is similar to UCLASS_MISC, but also includes UCLASS_I2C_EEPROM, UCLASS_RTC, and UCLASS_MTD. New drivers corresponding to a Linux-style nvmem device should be implemented as one of the previously-mentioned uclasses. The nvmem API acts as a compatibility layer to adapt the (slightly different) APIs of these uclasses. It also handles the lookup of nvmem cells. While nvmem devices can be accessed directly, they are most often used by reading/writing contiguous values called "cells". Cells typically hold information like calibration, versions, or configuration (such as mac addresses). nvmem devices can specify "cells" in their device tree: qfprom: eeprom@700000 { #address-cells = <1>; #size-cells = <1>; reg = <0x00700000 0x100000>; /* ... */ tsens_calibration: calib@404 { reg = <0x404 0x10>; }; }; which can then be referenced like: tsens { /* ... */ nvmem-cells = <&tsens_calibration>; nvmem-cell-names = "calibration"; }; The tsens driver could then read the calibration value like: struct nvmem_cell cal_cell; u8 cal[16]; nvmem_cell_get_by_name(dev, "calibration", &cal_cell); nvmem_cell_read(&cal_cell, cal, sizeof(cal)); Because nvmem devices are not all of the same uclass, supported uclasses must register a nvmem_interface struct. This allows CONFIG_NVMEM to be enabled without depending on specific uclasses. At the moment, nvmem_interface is very bare-bones, and assumes that no initialization is necessary. However, this could be amended in the future. Although I2C_EEPROM and MISC are quite similar (and could likely be unified), they present different read/write function signatures. To abstract over this, NVMEM uses the same read/write signature as Linux. In particular, short read/writes are not allowed, which is allowed by MISC. The functionality implemented by nvmem cells is very similar to that provided by i2c_eeprom_partition. "fixed-partition"s for eeproms does not seem to have made its way into Linux or into any device tree other than sandbox. It is possible that with the introduction of this API it would be possible to remove it. Signed-off-by: Sean Anderson <sean.anderson@seco.com>
2022-05-28doc/efi: add firmware management protocol to the documentationVincent Stehlé1-0/+6
The firmware management protocol can be used to manage device firmware. U-Boot can be configured to provide an implementation. Document the related functions in the API section. Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-02-25clk: Add driver API to HTML docsSean Anderson1-0/+6
This converts the existing driver API docs (clk-uclass.h) to kernel doc format and adds them to the HTML documentation. Because the kernel doc sphinx converter does not handle functions in structs very well, the individual methods are documented separately. This is primarily inspired by the phylink documentation [1], which uses this trick extensively. [1] https://www.kernel.org/doc/html/latest/networking/kapi.html#c.phylink_mac_ops Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20211222171114.3091780-5-seanga2@gmail.com
2022-02-25clk: Add client API to HTML docsSean Anderson2-0/+14
This converts the existing client (aka clk.h) documentation to kernel doc format, and adds it to the HTML docs. I have tried to preserve existing comments as much as possible, refraining from semantic changes. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20211222171114.3091780-4-seanga2@gmail.com [rebased onto u-boot/master and resolved conflicts] Signed-off-by: Sean Anderson <seanga2@gmail.com>
2022-01-15doc: add include/dm/fdtaddr.h to the HTML documentationPatrick Delaunay1-0/+1
Correct Sphinx style comments in include/dm/fdtaddr.h and add the devfdt API to the HTML documentation; these functions are NOT compatible with live tree. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-15doc: add include/dm/of*.h to the HTML documentationPatrick Delaunay1-0/+9
Correct Sphinx style comments in include/dm/ofnode.h and add the device tree node API to the HTML documentation; the ofnode functions are compatible with Live tree or with flat device tree. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-15doc: add include/dm/read.h to the HTML documentationPatrick Delaunay1-0/+1
Correct Sphinx style comments in include/dm/read.h and add the device read from device tree API to the HTML documentation. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-15doc: add include/dm/devres.h to the HTML documentationPatrick Delaunay1-0/+1
Correct Sphinx style comments in include/dm/devres.h and add the driver model device resource API, devres_*(), to the HTML documentation. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-15doc: add include/dm/device.h to the HTML documentationPatrick Delaunay1-0/+5
Correct Sphinx style comments in include/dm/device.h and add the driver model device API to the HTML documentation. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-15doc: add include/dm/platdata.h to the HTML documentationPatrick Delaunay1-0/+1
Correct Sphinx style comments in include/dm/platdata.h and add the associated API to the HTML documentation. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-15doc: add include/dm/lists.h to the HTML documentationPatrick Delaunay1-0/+1
Correct Sphinx style comments in include/dm/lists.h and add the list API to the HTML documentation. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-15doc: add include/dm/root.h to the HTML documentationPatrick Delaunay1-0/+1
Correct Sphinx style comments in include/dm/devres.h and add the associated driver model API to the HTML documentation. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-15doc: add include/dm/uclass.h to the HTML documentationPatrick Delaunay2-0/+10
Correct Sphinx style comments in include/dm/uclass.h and add the driver model UCLASS API to the HTML documentation. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-11-20doc: add include/lmb.h to the HTML documentationHeinrich Schuchardt2-0/+8
Correct Sphinx style comments in include/lmb.h Add the logical memory block API to the HTML documentation. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2021-10-21doc: add system reset to API documentationHeinrich Schuchardt2-0/+8
Complete the Sphinx documentation in include/sysreset.h Add the include to the generated HTML documentation of the U-Boot API. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-01-27doc: fix doc/develop/logging.rstHeinrich Schuchardt2-0/+7
Sphinx 3 builds fail due to doc/develop/logging.rst producing duplicate labels. Include logging.h only once in the API section and use cross-references for the enums log_level_t and log_category_t. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-12-19linker_lists: Fix alignment issueSimon Glass1-0/+59
The linker script uses alphabetic sorting to group the different linker lists together. Each group has its own struct and potentially its own alignment. But when the linker packs the structs together it cannot ensure that a linker list starts on the expected alignment boundary. For example, if the first list has a struct size of 8 and we place 3 of them in the image, that means that the next struct will start at offset 0x18 from the start of the linker_list section. If the next struct has a size of 16 then it will start at an 8-byte aligned offset, but not a 16-byte aligned offset. With sandbox on x86_64, a reference to a linker list item using ll_entry_get() can force alignment of that particular linker_list item, if it is in the same file as the linker_list item is declared. Consider this example, where struct driver is 0x80 bytes: ll_entry_declare(struct driver, fred, driver) ... void *p = ll_entry_get(struct driver, fred, driver) If these two lines of code are in the same file, then the entry is forced to be aligned at the 'struct driver' alignment, which is 16 bytes. If the second line of code is in a different file, then no action is taken, since the compiler cannot update the alignment of the linker_list item. In the first case, an 8-byte 'fill' region is added: .u_boot_list_2_driver_2_testbus_drv 0x0000000000270018 0x80 test/built-in.o 0x0000000000270018 _u_boot_list_2_driver_2_testbus_drv .u_boot_list_2_driver_2_testfdt1_drv 0x0000000000270098 0x80 test/built-in.o 0x0000000000270098 _u_boot_list_2_driver_2_testfdt1_drv *fill* 0x0000000000270118 0x8 .u_boot_list_2_driver_2_testfdt_drv 0x0000000000270120 0x80 test/built-in.o 0x0000000000270120 _u_boot_list_2_driver_2_testfdt_drv .u_boot_list_2_driver_2_testprobe_drv 0x00000000002701a0 0x80 test/built-in.o 0x00000000002701a0 _u_boot_list_2_driver_2_testprobe_drv With this, the linker_list no-longer works since items after testfdt1_drv are not at the expected address. Ideally we would have a way to tell gcc not to align structs in this way. It is not clear how we could do this, and in any case it would require us to adjust every struct used by the linker_list feature. One possible fix is to force each separate linker_list to start on the largest possible boundary that can be required by the compiler. However that does not seem to work on x86_64, which uses 16-byte alignment in this case but needs 32-byte alignment. So add a Kconfig option to handle this. Set the default value to 4 so as to avoid changing platforms that don't need it. Update the ll_entry_start() accordingly. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-11-05doc: add sandbox APIHeinrich Schuchardt2-0/+10
Add sandbox API to generated HTML documentation Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-30lib: Add getoptSean Anderson2-0/+9
Some commands can get very unweildy if they have too many positional arguments. Adding options makes them easier to read, remember, and understand. This implementation of getopt has been taken from barebox, which has had option support for quite a while. I have made a few modifications to their version, such as the removal of opterr in favor of a separate getopt_silent function. In addition, I have moved all global variables into struct getopt_context. The getopt from barebox also re-orders the arguments passed to it so that non-options are placed last. This allows users to specify options anywhere. For example, `ls -l foo/ -R` would be re-ordered to `ls -l -R foo/` as getopt parsed the options. However, this feature conflicts with the const argv in cmd_tbl->cmd. This was originally added in 54841ab50c ("Make sure that argv[] argument pointers are not modified."). The reason stated in that commit is that hush requires argv to stay unmodified. Has this situation changed? Barebox also uses hush, and does not have this problem. Perhaps we could use their fix? I have assigned maintenance of getopt to Simon Glass, as it is currently only used by the log command. I would also be fine maintaining it. Signed-off-by: Sean Anderson <seanga2@gmail.com>
2020-10-22doc: Document timer APISean Anderson2-0/+9
This adds kerneldocs for <timer.h>. I don't know who should maintain doc/api/timer.rst, since the timer subsystem seems to be maintained by SoC maintainers. MAINTAINERS is left un-updated for the moment. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-10-08pinctrl: Reformat documentation in dm/pinctrl.hSean Anderson2-0/+8
This normalizes the documentation to conform to kernel-doc style [1]. It also moves the documentation for pinctrl_ops inline, and adds argument and return-value documentation. I have kept the usual function style for these comments. I could not find any existing examples of function documentation inside structs. [1] https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-07-12efi_loader: prepare for read only OP-TEE variablesHeinrich Schuchardt1-0/+2
We currently have two implementations of UEFI variables: * variables provided via an OP-TEE module * variables stored in the U-Boot environment Read only variables are up to now only implemented in the U-Boot environment implementation. Provide a common interface for both implementations that allows handling read-only variables. As variable access is limited to very few source files put variable related definitions into new include efi_variable.h instead of efi_loader. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-06-14doc: random number generationHeinrich Schuchardt2-0/+18
Add random number generation APIs to the HTML documentation. Fix style issues. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-05-25doc: dfu: add DFU to HTML documentationHeinrich Schuchardt2-0/+8
Add the device firmware update functions to the generated HTML documentation. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Lukasz Majewski <lukma@denx.de>
2020-05-09doc: add Unicode functions to API descriptionHeinrich Schuchardt2-0/+8
Add include/charset.h to generated HTML documentation Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-05-09efi_selftest: add unit test functions to HTML documentationHeinrich Schuchardt1-0/+9
Add the UEFI unit test helper functions to the generated HTML documentation. Correct some documentation texts in include/efi_selftest.h. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-04-16efi_loader: function descriptions efi_watchdog.cHeinrich Schuchardt1-0/+6
Correct function descriptions in efi_watchdog.c. Add the descriptions to the generated HTML documentation. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-04-16efi_loader: function descriptions efi_unicode_collation.cHeinrich Schuchardt1-0/+6
Correct function descriptions in efi_unicode_collation.c Add the Unicode collation protocol to the generated HTML documentation. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-02-28doc/efi: add load file 2 protocol to HTML documentationHeinrich Schuchardt1-0/+9
The load file 2 protocol can be used by the Linux kernel to load the initial RAM disk. U-Boot can be configured to provide an implementation. Add a description to the UEFI overview and document the related functions in the API section. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-01-15efi_loader: document functions in efi_rng.cHeinrich Schuchardt1-0/+6
Add the missing Sphinx documentation. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-09-06doc: UEFI API documentationHeinrich Schuchardt1-0/+33
Add some more files to the UEFI API documentation. Correct some Sphinx comments. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-07-24doc: Move existing rst files into api sub-directoryBin Meng4-0/+223
Currently the Sphinx doc only contains API descriptions of several U-Boot subsystems. For future extension, group these existing docs into an API sub-directory. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>