diff options
Diffstat (limited to 'doc/develop')
| -rw-r--r-- | doc/develop/codingstyle.rst | 48 | ||||
| -rw-r--r-- | doc/develop/devicetree/control.rst | 58 | ||||
| -rw-r--r-- | doc/develop/driver-model/spi-howto.rst | 4 | ||||
| -rw-r--r-- | doc/develop/environment.rst | 40 | ||||
| -rw-r--r-- | doc/develop/historical/generic_board.rst | 6 | ||||
| -rw-r--r-- | doc/develop/index.rst | 2 | ||||
| -rw-r--r-- | doc/develop/memory.rst | 9 | ||||
| l--------- | doc/develop/patman.rst | 1 | ||||
| -rw-r--r-- | doc/develop/pmbus.rst | 637 | ||||
| -rw-r--r-- | doc/develop/pytest/usage.rst | 2 | ||||
| -rw-r--r-- | doc/develop/release_cycle.rst | 34 | ||||
| -rw-r--r-- | doc/develop/security.rst | 2 | ||||
| -rw-r--r-- | doc/develop/sending_patches.rst | 71 | ||||
| -rw-r--r-- | doc/develop/statistics/u-boot-stats-v2026.07.rst | 884 | ||||
| -rw-r--r-- | doc/develop/testing.rst | 2 |
15 files changed, 1719 insertions, 81 deletions
diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst index 26881cf3900..b8d2bf23a54 100644 --- a/doc/develop/codingstyle.rst +++ b/doc/develop/codingstyle.rst @@ -24,54 +24,6 @@ The following rules apply: <https://peps.python.org/pep-0008/>`_. Use `pylint <https://github.com/pylint-dev/pylint>`_ for checking the code. -.. _b4_contrib: - -* Use the `b4 <https://b4.docs.kernel.org/en/latest/>`__ tool to prepare and - send your patches. b4 has become the preferred tool to sending patches for many - Linux kernel contributors, and U-Boot ships with a ready-to-use ``.b4-config`` that - targets ``[email protected]`` and integrates with ``scripts/get_maintainer.pl`` for - recipient discovery. - - Start a topical series with ``b4 prep`` and keep the commits organised with - ``git rebase -i``. ``b4 prep --edit-cover`` opens an editor for the cover - letter, while ``b4 prep --auto-to-cc`` collects reviewers and maintainers from - both the configuration file and ``scripts/get_maintainer.pl``. - - .. code-block:: bash - - b4 prep -n mmc-fixes - git rebase -i origin/master - b4 prep --edit-cover - b4 prep --auto-to-cc - - Run the style checks before sending. ``b4 prep --check`` wraps the existing - tooling so you see the output from ``scripts/checkpatch.pl`` alongside b4's - own validation. You can always invoke ``scripts/checkpatch.pl`` directly for - additional runs. - - .. code-block:: bash - - b4 prep --check - - When the series is ready, use ``b4 send``. Begin with ``--dry-run`` to review - the generated emails and ``--reflect`` to copy yourself for records before - dispatching to ``[email protected]``. - - .. code-block:: bash - - b4 send --dry-run - b4 send --reflect - b4 send - - After reviews arrive, collect Acked-by/Tested-by tags with ``b4 trailers -u`` - and fold them into your commits before resending the updated series. - - .. code-block:: bash - - b4 trailers -u - git rebase -i origin/master - b4 send - * Run ``scripts/checkpatch.pl`` directly or via ``b4 prep --check`` so that all issues are resolved *before* posting on the mailing list. For more information, read :doc:`checkpatch`. diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index 634114af59a..7d6117d5c4b 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -232,6 +232,64 @@ outside the U-Boot repository. You can use `DEVICE_TREE_INCLUDES` Kconfig option to specify a list of .dtsi files that will also be included when building .dtb files. +Scripts embedded in control DTB +------------------------------- + +The `DEVICE_TREE_INCLUDES` option can also be used to make the control +DTB serve double duty as a FIT image. By including a `scripts.dtsi` +file containing something like:: + + / { + images { + default = "boot"; + boot { + description = "Bootscript"; + data = /incbin/("boot.sh"); + type = "script"; + compression = "none"; + }; + factory-reset { + description = "Script for performing factory reset"; + data = /incbin/("factory-reset.sh"); + type = "script"; + compression = "none"; + }; + }; + }; + +one can call those scripts using the `source` command in the U-Boot shell:: + + source ${fdtcontroladdr}:boot + +or just ``source ${fdtcontroladdr}`` for invoking the default. + +Since one does not need to separately build a "real" FIT image +containing those scripts, this simplifies both the build process and +the boot logic, as the latter does not need to first load the FIT +image from storage. + +Another advantage is that when the bootloader and boot script must be +updated together, it is easier to achieve a guaranteed atomic update +when the boot script is embedded inside the U-Boot binary, instead of +stored separately. + +For the above to work, one must enable the `CONTROL_DTB_AS_FIT` config +option, which will (when the address passed to the `source` command is +the address of U-Boot's control DTB) elide certain sanity checks that +are normally done: With the above `.dtsi` snippet, the control DTB +does not quite become a "real" FIT image - it lacks `timestamp` and +`description` properties, but more importantly, FIT images cannot +contain nodes with `@` in their names (unit addresses) anywhere, and +the control DTB obviously does have such nodes. + +This is not a security problem, as the control DTB is necessarily +trusted. In any secure boot setup where the bootloader is verified, +that mechanism must also include verification of the control DTB. So +in fact, since the scripts embedded this way are then also +automatically verified, it simplifies implementation of secure +boot. When using a separate FIT image, one must build it with +appropriate signatures, just as when building a FIT image containing a +kernel/dtb/initramfs. Devicetree bindings schema checks --------------------------------- diff --git a/doc/develop/driver-model/spi-howto.rst b/doc/develop/driver-model/spi-howto.rst index 9dc3b9b4aac..65dd50e7d55 100644 --- a/doc/develop/driver-model/spi-howto.rst +++ b/doc/develop/driver-model/spi-howto.rst @@ -649,8 +649,8 @@ board. Prepare patches and send them to the mailing lists -------------------------------------------------- -You can use 'tools/patman/patman' to prepare, check and send patches for -your work. See tools/patman/README for details. +You can prepare, check and send patches for your work using the tools described +in :doc:`/develop/sending_patches`. A little note about SPI uclass features --------------------------------------- diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst index e46cd39d601..a7ed4aab0a5 100644 --- a/doc/develop/environment.rst +++ b/doc/develop/environment.rst @@ -49,3 +49,43 @@ The signature of the callback functions is:: include/search.h The return value is 0 if the variable change is accepted and 1 otherwise. + +Flags for environment variables +------------------------------- + +Environment flags validate the values given to environment variables and +restrict how environment variables can be changed. + +The static list is configured with CONFIG_ENV_FLAGS_LIST_STATIC. The list +must be in the following format:: + + type_attribute = [s|d|x|b|i|m] + access_attribute = [a|r|o|c|w] + attributes = type_attribute[access_attribute] + entry = variable_name[:attributes] + list = entry[,list] + +The type attributes are: + +* s - String (default) +* d - Decimal +* x - Hexadecimal +* b - Boolean ([1yYtT|0nNfF]) +* i - IP address, if networking is enabled +* m - MAC address, if networking is enabled + +The access attributes are: + +* a - Any (default) +* r - Read-only +* o - Write-once +* c - Change-default +* w - Writeable, if CONFIG_ENV_WRITEABLE_LIST is enabled + +CONFIG_ENV_FLAGS_LIST_DEFAULT defines the ``.flags`` variable in the +default or embedded environment. Any association in ``.flags`` overrides +an association in the static list. + +If CONFIG_REGEX is defined, the variable name is evaluated as a regular +expression. This allows multiple variables to define the same flags without +explicitly listing them all. diff --git a/doc/develop/historical/generic_board.rst b/doc/develop/historical/generic_board.rst index 12550a140e0..17a92687c5b 100644 --- a/doc/develop/historical/generic_board.rst +++ b/doc/develop/historical/generic_board.rst @@ -64,17 +64,17 @@ separate function calls so that they can easily be included or excluded for a particular architecture. It also makes it easier to adopt Graeme's initcall proposal when it is ready. -http://lists.denx.de/pipermail/u-boot/2012-January/114499.html +https://patch.msgid.link/[email protected]/ This series removes the dependency on generic relocation. So relocation happens as one big chunk and is still completely arch-specific. See the relocation series for a proposed solution to this for ARM: -http://lists.denx.de/pipermail/u-boot/2011-December/112928.html +https://patch.msgid.link/CAPnjgZ0jesqX1Y71S5xoYQDGPuARfOX48RGbU9Mw=P5HGYcOKg@mail.gmail.com/ or Graeme's recent x86 series v2: -http://lists.denx.de/pipermail/u-boot/2012-January/114467.html +https://patch.msgid.link/[email protected]/ Instead of moving over a whole architecture, this series takes the approach of simply enabling generic board support for an architecture. It is then up diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 3c044e67927..0b757e8601e 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -16,7 +16,6 @@ General docstyle kconfig memory - patman process release_cycle security @@ -50,6 +49,7 @@ Implementation logging makefiles menus + pmbus printf smbios spl diff --git a/doc/develop/memory.rst b/doc/develop/memory.rst index 5177229630d..3da39bb6c66 100644 --- a/doc/develop/memory.rst +++ b/doc/develop/memory.rst @@ -111,6 +111,15 @@ U-Boot Proper Flow This follows the same as in SPL flow. In board_init_f(), a part of memory is reserved at the end of RAM (see reserve_* functions in init_sequence_f) + #. Relocation address + + By default U-Boot will try to relocate below the 4GiB boundary. If + RELOC_ADDR_TOP is enabled U-Boot will look into the dram bank config of + gd->dram[] and try to relocate to the highest available bank. Use this + with caution as devices that can only DMA below 4GiB will misbehave + since their buffers may be allocated above the 32-bit boundary. + Boards can override thre relocation address via board_get_usable_ram_top(). + #. Code Relocation relocate_code() is called which relocates U-Boot code from the current diff --git a/doc/develop/patman.rst b/doc/develop/patman.rst deleted file mode 120000 index 0fcb7d61d40..00000000000 --- a/doc/develop/patman.rst +++ /dev/null @@ -1 +0,0 @@ -../../tools/patman/patman.rst
\ No newline at end of file diff --git a/doc/develop/pmbus.rst b/doc/develop/pmbus.rst new file mode 100644 index 00000000000..f5550541e83 --- /dev/null +++ b/doc/develop/pmbus.rst @@ -0,0 +1,637 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +PMBus support in U-Boot +======================= + +This document describes U-Boot's PMBus 1.x support: what it is for, +how it is structured, and how to add support for a new PMBus chipn +either from scratch from a chip datasheet or by porting an existing +Linux ``drivers/hwmon/pmbus/`` driver. + +.. contents:: + :local: + :depth: 2 + +Intent and scope +---------------- + +U-Boot's PMBus layer is not a hardware monitoring (hwmon) clone of +the Linux kernel's ``drivers/hwmon/pmbus/`` subsystem. Linux owns the +runtime side: continuous polling, sysfs publication, alert IRQ +handling, fan control loops. U-Boot owns the boot time side. Concretely +the U-Boot PMBus support exists to: + +* Identify the PMBus regulator(s) a board carries at boot: + ``MFR_ID``, ``MFR_MODEL``, ``MFR_REVISION`` reads, plus a quick + ``STATUS_WORD`` sanity check. +* Print telemetry so an operator can confirm rail voltages, input + current, and temperature before handing off to the kernel. One shot + reads, on demand, via the ``pmbus`` and ``regulator`` U-Boot + commands (``pmbus dev <name>; pmbus telemetry``, + ``regulator dev <name>; regulator value``). +* Decode chip alerts when a rail trips an over/under voltage, + over current, or thermal threshold; so a boot log shows why the + previous boot failed, before the kernel even comes up. +* Optionally trim a critical rail (typically the SoC core) before + the kernel takes over; "set the voltage prior to a kernel boot + to better protect the board". This is the existing + ``board/nxp/common/vid.c`` AVS path and any future per board + speed binning trim. + +Out of scope, by design: + +* No periodic polling. No worker thread. No background updates. +* No sysfs / procfs / userspace surface. U-Boot has none. +* No fan speed control loop. The kernel runs that. +* No long tail of virtual sensor registers (``PMBUS_VIRT_*``). +* No sensor caching / update timestamps. + +If you find yourself wanting any of those, the answer is "wait until +Linux comes up". Keep U-Boot's PMBus surface minimal. + +Architecture overview +--------------------- + +The framework is split into four layers (layer 3 comes in two +flavours, 3a and 3b), + +:: + + +----------------------------------------+ + | Layer 1: include/pmbus.h | + | Standard PMBus 1.x command codes, | + | numeric format enum, sensor class | + | enum, struct pmbus_driver_info, | + | decoder + transport prototypes, | + | STATUS_WORD bit names. | + +----------------------------------------+ + | Layer 2: lib/pmbus.c | + | Format decoders (LINEAR11/LINEAR16/| + | DIRECT) and encoder (LINEAR16), | + | two stage SMBus block read helper, | + | STATUS_*-bit print tables, generic | + | dispatcher pmbus_reg2data(). | + +----------------------------------------+ + | Layer 3a: drivers/power/regulator/ | + | <chip>.c | + | UCLASS_REGULATOR per chip drivers | + | ; one struct pmbus_driver_info | + | plus regulator set_value/get_value | + | ops. Optional: per chip identify() | + | hook to refine format from the | + | chip's own VOUT_MODE. | + +----------------------------------------+ + | Layer 3b: drivers/power/regulator/ | + | pmbus_generic.c | + | Catch all driver matching | + | compatible = "pmbus". | + | Auto detects format via VOUT_MODE | + | and PMBUS_QUERY where supported. | + | Use for compliant chips with no | + | per chip driver yet; ship | + | telemetry today, write a per chip | + | driver later only if quirks demand | + | it. | + +----------------------------------------+ + | Layer 4: board/<vendor>/<board>/ | + | <chip>_diag.c | + | Diagnostic commands only: | + | <chip>_info / <chip>_raw | + | Reads via regulator_get_value() | + | and lib/pmbus.c helpers. LINEAR / | + | DIRECT math NOT here. | + +----------------------------------------+ + +Generic vs. board specific separation rule. Layer 1, 2, and 3 +files are tree level and platform agnostic. Their comments may +reference only: + +* the PMBus 1.x specification, and +* chip manufacturer datasheets. + +Never a specific board, SoC, or product. Board-specific quirks +(a particular bus number, a particular slave address, a particular +PCB feedback divider, board local design notes) live exclusively in +``board/<vendor>/<board>/`` files. + +CLI commands +------------ + +The framework publishes one top level command, ``pmbus``, plus a +vendor namespace dispatcher so per chip code can register chip +specific extensions without touching the framework. + +Active device model +~~~~~~~~~~~~~~~~~~~ + +``pmbus`` mirrors the ``regulator`` command: select an active device +once, then operate on it across subcommands. The active device is +selected by I2C bus (decimal sequence number) and 7 bit address (hex, +``0x`` optional, à la ``i2c`` convention):: + + => pmbus dev 0:10 + pmbus: active i2c0:0x10 MFR_ID="MPS" MFR_MODEL="MPQ8785" vendor=mps + +The framework probes ``MFR_ID`` (in both natural and reverse byte +orders) at selection time, looks the result up in the chip match +registry populated by per chip code via ``pmbus_register_chip()``, +and caches the matched ``pmbus_driver_info``. All subsequent +subcommands consume that cached metadata. + +Standard subcommands +~~~~~~~~~~~~~~~~~~~~ + +:: + + pmbus list list UCLASS_REGULATOR devices (DM bound) + pmbus dev [<bus>:<addr>] show / select active PMBus device + pmbus info identification banner + driver_info + pmbus telemetry decoded VIN, VOUT, IIN, IOUT, TEMP + pmbus status decode every STATUS_* register + pmbus dump hex dump of every standard register + pmbus read <reg> [b|w|s] raw read (b=byte, w=word, s=string) + pmbus write <reg> <val> [b|w] raw write + pmbus clear [faults] issue CLEAR_FAULTS (03h) + pmbus vout [<uV>] read or set VOUT_COMMAND (microvolts) + pmbus scan [<bus>] PMBus aware probe of one or all I2C buses + +The ``<reg>`` argument accepts either a hexadecimal address +(``88``, ``0x`` optional) or a symbolic name (``READ_VIN``, +``VOUT_MODE``, ``MFR_ID``); symbolic names win when both parsed. +``<val>`` is hexadecimal too. Only ``pmbus vout``'s microvolt +argument and bus numbers are decimal. +Format selectors after the register select the SMBus transaction width: +``b`` for byte, ``w`` for 16 bit little endian word, +``s`` for the SMBus block read used by string registers. + +Decoded telemetry honours the active device's ``pmbus_driver_info``; +when no chip match has been registered, VOUT falls back to LINEAR16 +driven by ``VOUT_MODE`` and the other sensors fall back to LINEAR11. + +Vendor namespace +~~~~~~~~~~~~~~~~ + +Per chip drivers and board files publish chip specific subcommands +in the ``pmbus <vendor> ...`` namespace by calling +``pmbus_register_vendor_handler()`` at init time. The framework +dispatches ``pmbus mps last``, ``pmbus mps clear last``, and +``pmbus mps clear force`` to the MPS handler when the active +device matches the ``mps`` vendor. Additional vendor handlers for +``lltc``, ``renesas``, etc. land alongside the per chip drivers +that need them. + +Relationship to ``vdd_override`` / ``vdd_read`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The NXP Layerscape ``vdd_override <mV>`` and ``vdd_read`` commands +remain available in their original form for compatibility with +existing AVS production scripts. The new ``pmbus vout`` and +``pmbus vout <uV>`` subcommands cover the read and single shot +write paths against the same chips, but do not implement +``vdd_override``'s full sequence (board drop compensation, fuse +target derivation, multi step convergence loop, atomic +``PAGE_PLUS_WRITE`` block transaction, ``WRITE_PROTECT`` dance). +For interactive bring up ``pmbus vout`` is sufficient; for +production AVS, ``vdd_override`` stays canonical. + +Lifecycle: from board boot to Linux handoff +------------------------------------------- + +The PMBus framework spans the entire U-Boot lifecycle. This section +walks the boot timeline phase by phase, showing when each piece +comes online and how the regulator uclass and the ``pmbus`` CLI +converge on the same chip. + +Timeline overview +~~~~~~~~~~~~~~~~~ + +:: + + Phase 0 chip power on chip ramps to NVM default VOUT + Phase 1 boot ROM / SPL / TF-A PMBus typically untouched + Phase 2 U-Boot relocation, DM init regulators bound, not probed + Phase 3 first regulator probe chip driver runs, framework lights up + Phase 4 board hooks / boot scripts snapshot, AVS trim, gating + Phase 5 Linux handoff DT passed, chip state preserved + Phase 6 Linux runtime kernel pmbus driver takes over + +Phase 0: chip power on +~~~~~~~~~~~~~~~~~~~~~~ + +When the regulator chip receives its input voltage, it ramps its +output to the VOUT default programmed into its NVM at factory +provisioning. PMBus is silent: no software runs anywhere on the +SoC yet. + +Phase 1: pre U-Boot stages +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Boot ROMs, secondary boot loaders (SPL, ARM TF-A BL2 / BL31) +typically do not touch PMBus. They focus on PLLs, DDR PHY init, +and bringing up enough hardware to load the next stage. Some +platforms have a pre U-Boot AVS path in board specific TF-A +code that writes ``VOUT_COMMAND`` from a fuse derived target; +that path is independent of the U-Boot framework described here. + +Phase 2: U-Boot relocation and DM init +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After relocation, U-Boot binds device tree nodes to drivers but +does not probe them. UCLASS_REGULATOR devices for PMBus chips +are bound (driver and DT match resolved) but the ``.probe`` +callback has not run yet. + +Framework state at this point: + +* chip match registry: empty +* vendor handler registry: empty +* active device: none +* regulator uclass: devices bound, none probed + +Phase 3: lazy regulator probe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The first caller into the regulator uclass for a given chip +triggers the chip driver's ``.probe``. Typical first callers: + +* a board ``EVENT_SPY`` at ``EVT_LAST_STAGE_INIT`` (boot snapshot) +* a U-Boot script: ``regulator dev <name>; regulator value`` +* the ``pmbus dev <name>`` CLI command (resolves to the regulator) +* another DT consumer with a ``regulator-supplies`` reference + +The probe chain looks like this:: + + <chip>_probe(dev) + pmbus_regulator_probe_common(dev, &<chip>_info, page) + dev_read_addr(dev) -> reg = <addr> + i2c_get_chip(dev->parent, addr) -> I2C chip handle + priv->i2c_dev = handle + priv->info = &<chip>_info + priv->page = page + (page > 0) write PMBUS_PAGE + <chip>_identify_vout(priv->i2c_dev) [optional] + read VOUT_MODE; refine info->format[PSC_VOLTAGE_OUT] + pmbus_regulator_apply_voltage_scale(dev, fb_div) [optional] + write PMBUS_VOUT_SCALE_LOOP if DT property set + pmbus_register_chip(&<chip>_match) [idempotent] + pmbus_register_vendor_handler(&<chip>_op) [idempotent] + +Once probed, three independent surfaces are functional against +the same chip: + +* the regulator uclass API (``regulator_get_value``, + ``regulator_set_value``, ``regulator_get_enable``, + ``regulator_set_enable``) +* the ``pmbus`` CLI (chip is reachable by name through + ``pmbus_resolve_by_name()``, by raw ``<bus>:<addr>`` through + ``pmbus_set_active()``) +* the chip's vendor extension subcommands (``pmbus <vendor> ...``) + +Phase 4: board hooks and boot scripts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Boards hook the boot flow at well known points to drive board +specific PMBus behaviour. The framework prescribes none of these; +they are conventions: + +* boot time rail snapshot. An ``EVENT_SPY`` at + ``EVT_LAST_STAGE_INIT`` reads telemetry through the regulator + uclass and prints a one shot summary to the console. Useful + for operator visibility on serial during bring up. + +* pre kernel rail trim (AVS). A board hook in + ``board_late_init`` or a custom event spy reads a fuse derived + target voltage and calls ``regulator_set_value_force()`` to + trim the SoC core rail before kernel handoff. + +* Linux handoff gate. A bootcmd reads the rail voltage + through the regulator command and refuses to boot Linux if + the rail is outside the expected range. + +Phase 5: Linux handoff +~~~~~~~~~~~~~~~~~~~~~~ + +When U-Boot transfers control to Linux, it passes the device +tree (potentially patched). The DT compatible strings for PMBus +regulators must match those in the upstream kernel binding so +the kernel's ``drivers/hwmon/pmbus/<chip>.c`` picks them up. +Property names are shared with the kernel binding +(``regulator-name``, ``regulator-min-microvolt``, +``mps,vout-fb-divider-ratio-permille``, etc.); see "DT alignment +with Linux" below. + +The chip itself is left in the state U-Boot wrote it to. If +U-Boot trimmed VOUT, the chip stays at the trimmed voltage +through handoff. ``CLEAR_FAULTS`` state is preserved unless an +operator explicitly issued one. + +Phase 6: Linux runtime +~~~~~~~~~~~~~~~~~~~~~~ + +Linux's ``drivers/hwmon/pmbus/pmbus_core.c`` probes the chip, +exposes telemetry under ``/sys/class/hwmon``, and takes over +runtime voltage management through its regulator subsystem. +The hwmon framework polls periodically; U-Boot does not. + +Operation paths through the regulator uclass +-------------------------------------------- + +After the first probe completes, calls into the regulator uclass +for a PMBus chip flow through the shared helper. + +Read VOUT:: + + regulator_get_value(dev) + -> dm_regulator_ops->get_value + -> pmbus_regulator_get_value(dev) + pmbus_regulator_select_page(priv) + pmbus_read_byte(priv->i2c_dev, VOUT_MODE, &mode) + pmbus_read_word(priv->i2c_dev, READ_VOUT, &raw) + pmbus_reg2data(priv->info, PSC_VOLTAGE_OUT, raw, mode) + -> reg2data_linear16 (mode = 0) + -> reg2data_direct (chip configured for DIRECT) + return engineering value (microvolts) + +Write VOUT:: + + regulator_set_value(dev, uV) + -> dm_regulator_ops->set_value + -> pmbus_regulator_set_value(dev, uV) + pmbus_regulator_select_page(priv) + pmbus_read_byte(VOUT_MODE) + check (mode == LINEAR) [LINEAR16 only today] + raw = pmbus_data2reg_linear16(uV, mode) + dm_i2c_write(VOUT_COMMAND, raw) + +Read / write enable bit:: + + regulator_get_enable(dev) + -> pmbus_regulator_get_enable(dev) + pmbus_read_byte(OPERATION) & PB_OPERATION_ON + + regulator_set_enable(dev, on) + -> pmbus_regulator_set_enable(dev, on) + read OPERATION, set or clear PB_OPERATION_ON, write back + +Bus traffic per call: + +* ``get_value`` : 1 byte read (VOUT_MODE) + 1 word read (READ_VOUT) + + 1 byte write (PAGE) when ``page > 0`` +* ``set_value`` : 1 byte read (VOUT_MODE) + 1 word write (VOUT_COMMAND) + + 1 byte write (PAGE) when ``page > 0`` +* ``get_enable`` : 1 byte read (OPERATION) +* ``set_enable`` : 1 byte read (OPERATION) + 1 byte write (OPERATION) + +Common board hook patterns +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Boot time rail snapshot:: + + static int my_board_pmbus_snapshot(void) + { + struct udevice *reg; + + if (regulator_get_by_platname("MY_RAIL", ®)) + return 0; + printf("MY_RAIL: VOUT = %d uV, enabled = %d\n", + regulator_get_value(reg), + regulator_get_enable(reg)); + return 0; + } + EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, my_board_pmbus_snapshot); + +The first call to ``regulator_get_value()`` triggers the chip +driver's ``.probe``, which seeds the chip match and vendor +extension registries. Subsequent ``pmbus`` CLI commands work +without further setup. + +Pre kernel rail trim (AVS):: + + int board_late_init(void) + { + struct udevice *reg; + int target_uV = compute_avs_target(); + + if (regulator_get_by_platname("VDD_CORE", ®)) + return 0; + return regulator_set_value_force(reg, target_uV); + } + +Use ``regulator_set_value_force()`` when the target may sit +outside the DT declared ``regulator-min-microvolt`` / +``regulator-max-microvolt`` range; force bypasses the bounds +check. + +Adding a new PMBus chip from scratch +------------------------------------ + +Use this path when the chip has no Linux driver yet, or when you want +to validate the U-Boot port against the datasheet alone. + +1. Confirm PMBus 1.x compliance level. Locate in the chip + datasheet: + + which PMBus standard command codes the chip implements + (``READ_VIN``, ``READ_VOUT``, ``STATUS_WORD``, ``MFR_ID`` ...), + which numeric format(s) it uses for VOUT (LINEAR16 with the + exponent in ``VOUT_MODE``, DIRECT with chip specific m/b/R, or + VID with one of the documented VRM tables), + which numeric format it uses for VIN, IIN, IOUT, TEMPERATURE + (most commonly LINEAR11; some MPS / MPS derivative chips use + DIRECT instead), + how many output rails it exposes (single page parts vs. + multi rail PMBus pages). + +2. Declare a ``struct pmbus_driver_info``. Wire each sensor + class to one ``enum pmbus_data_format``, plus the m/b/R triple if + the format is DIRECT:: + + static struct pmbus_driver_info chipname_info = { + .pages = 1, + .format[PSC_VOLTAGE_IN] = pmbus_fmt_direct, + .format[PSC_VOLTAGE_OUT] = pmbus_fmt_linear, + .format[PSC_CURRENT_OUT] = pmbus_fmt_direct, + .format[PSC_TEMPERATURE] = pmbus_fmt_direct, + .m[PSC_VOLTAGE_IN] = 4, .R[PSC_VOLTAGE_IN] = 1, + .m[PSC_CURRENT_OUT] = 16, .R[PSC_CURRENT_OUT] = 0, + .m[PSC_TEMPERATURE] = 1, .R[PSC_TEMPERATURE] = 0, + }; + +3. Bind to a DT compatible. Use the lowercase ``vendor,chip`` + tuple Linux uses (see "DT alignment with Linux" below). Add the + driver under ``drivers/power/regulator/`` matching the existing + skeleton (``fan53555.c``, ``pca9450.c``). + +4. Rely on the DT binding from the Linux kernel which is imported into + U-Boot under ``dts/upstream/Bindings/`` (for PMBus chips, + ``dts/upstream/Bindings/hwmon/pmbus/``). + +5. Smoke test. With the chip wired up in DT:: + + => regulator dev <name> + => regulator value + => regulator info + + Numbers should match the bench measurement to within the chip's + advertised LSB. + +Porting an existing Linux PMBus driver to U-Boot +------------------------------------------------ + +When the chip already has a ``linux/drivers/hwmon/pmbus/<chip>.c``, +that driver is the authoritative reference for format, coefficients, +and quirks. Take what carries; leave what does not. + +What carries verbatim +~~~~~~~~~~~~~~~~~~~~~ + +* Numeric formats (``format[PSC_*]``). +* DIRECT coefficients (``m[]``, ``b[]``, ``R[]``). +* Per page count and per page functionality bits (``pages``, + ``func[]``). +* VOUT_MODE driven per chip identify hook (e.g. MPQ8785's + switch between LINEAR16 and VID coerced DIRECT m=64 R=1). +* Vendor register addresses for chip specific quirks (fault + history, scale-loop, page mapping). + +What does not carry +~~~~~~~~~~~~~~~~~~~~~~~ + +* ``hwmon_device_register()`` and the attribute groups it consumes. +* ``struct pmbus_data`` / ``update_lock`` / ``last_updated`` + U-Boot has no caching layer. +* ALERT# IRQ wiring; U-Boot is single threaded boot code. +* Fan control hooks (``read_fan_*``, ``set_pwm_*``). +* Virtual register handling (``PMBUS_VIRT_READ_VIN_*`` etc.); those + are entirely a hwmon publication aid. +* ``module_i2c_driver(...)`` and ``MODULE_*`` macros; U-Boot uses + ``U_BOOT_DRIVER(...)``. + +Worked example: porting MPQ8785 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Linux's ``drivers/hwmon/pmbus/mpq8785.c`` is 193 LOC; the U-Boot +equivalent is ~150 LOC. + +The ``mpq8785_info`` struct transcribes verbatim:: + + .pages = 1, + .format[PSC_VOLTAGE_IN] = direct, .m[PSC_VOLTAGE_IN] = 4, .R[PSC_VOLTAGE_IN] = 1, + .format[PSC_CURRENT_OUT] = direct, .m[PSC_CURRENT_OUT] = 16, .R[PSC_CURRENT_OUT] = 0, + .format[PSC_TEMPERATURE] = direct, .m[PSC_TEMPERATURE] = 1, .R[PSC_TEMPERATURE] = 0, + +The VOUT format is decided at probe time from VOUT_MODE bits[7:5] : +mode 0 means LINEAR16, mode 1 or 2 means DIRECT m=64 R=1 (the chip's +"VID" mode is coerced to DIRECT by the driver). Translate Linux's +``mpq8785_identify()`` 1:1. + +The per chip quirks that carry over: + +* MPS NVM string byte order: chip stores ``S P M`` for the human + string ``MPS``. ``pmbus_read_string()`` accepts a ``reverse_bytes`` + flag for this case. +* ``mps,vout-fb-divider-ratio-permille`` DT property maps to + ``VOUT_SCALE_LOOP`` write at probe time. + +The quirks that do not carry over: + +* The ``PMBUS_VIRT_*`` virtual sensor wiring. Drop entirely. +* The ``hwmon_chip_info`` attribute group registration. +* The ``MODULE_AUTHOR`` / ``MODULE_LICENSE`` declarations. + +Using the generic ``compatible = "pmbus"`` driver +------------------------------------------------- + +When a board carries a PMBus chip without a per chip U-Boot driver, +the catch all ``drivers/power/regulator/pmbus_generic.c`` (Layer 3b) +binds against ``compatible = "pmbus"``. It auto detects format via +``VOUT_MODE`` and ``PMBUS_QUERY`` (where the chip supports it) and +provides telemetry + voltage set/get against the standard PMBus 1.x +subset. + +Decision tree: + +1. Try the generic driver first. Add the regulator node to the + board DT with ``compatible = "pmbus"`` plus the standard + regulator properties. Boot, run ``regulator value``, compare + against bench measurement. +2. Switch to a per chip driver only when the generic one is + wrong: telemetry shows wrong values (chip uses DIRECT with + non default coefficients), an alert can't be decoded (chip has + vendor specific status bits), AVS is needed (the boot path has + to actively trim VOUT before kernel handoff), or the chip has an + ADDR-pin auto promotion / VID coercion / vendor register quirk. + +DT alignment with Linux +----------------------- + +The same ``.dts`` file should work under both U-Boot (BL33) and Linux +post handoff. To make that possible: + +* Reuse the upstream Linux compatible for every PMBus chip. Look + in ``linux/Documentation/devicetree/bindings/hwmon/pmbus/`` and + ``linux/Documentation/devicetree/bindings/regulator/``. The + ``<vendor>,<chip>`` tuple from the kernel binding goes into U-Boot's + ``of_match_table`` unchanged. +* Reuse Linux property names verbatim: ``regulator-name``, + ``regulator-min-microvolt``, ``regulator-max-microvolt``, + ``regulator-boot-on``, ``regulator-always-on``, + ``mps,vout-fb-divider-ratio-permille``, etc. +* The DT binding is the kernel's, imported under + ``dts/upstream/Bindings/`` (PMBus chips live in + ``dts/upstream/Bindings/hwmon/pmbus/``). + +Multi rail/multi page chips (e.g. ISL68137 with seven outputs) +declare each rail as a child regulator node with ``reg = <page>``; +each child binds as a UCLASS_REGULATOR with that PMBus PAGE setting +applied at every read/write. + +Common pitfalls +--------------- + +These have all bitten contributors during nbxv3 bring up; record them +here so the next port doesn't repeat them. + +* VOUT_MODE/DIRECT format confusion. Most generic PMBus call + sites assume LINEAR16. Several MPS chips report VOUT in DIRECT + format with chip specific m/b/R after a single VOUT_MODE read, + the same chip read at the same address produces different + numbers depending on the format the driver applies. Always read + ``VOUT_MODE`` at probe time and switch the decoder accordingly. + Linux's per chip ``identify()`` callbacks document the exact + rules; copy them rather than guessing. +* SMBus block read protocol. Some I2C controllers strict check + block read transactions: the master must read the length byte + first, then reissue the read for the payload. Over reading a + fixed length and ignoring the length byte works on lenient + controllers but errors on strict ones. ``pmbus_read_string()`` + does the two stage read; use it. +* I2C bus number stability. ``uclass_get_device_by_seq()`` + uses the DT alias index (``i2c0`` -> ``UCLASS_I2C`` seq 0) when + aliases are declared, otherwise falls back to probe order which + varies with which controllers are enabled in the defconfig. + Always declare DT aliases for I2C buses you reference by index. +* ADDR-pin auto addressessing. Some chips (notably MPS parts) decode + their PMBus 7-bit address from an external resistor divider on + ADDR_VBOOT. The "default" address in the datasheet is the + factory fused slot; a board with a different divider or a die + with a different revision can land in another window. If the + driver hardcodes the default and the board side scan finds the + chip in another window, auto promote the working address rather + than failing the probe. +* MFR string byte order. Most PMBus chips return ``MFR_ID`` + characters in human order. Some MPS personalities reverse them. + Pass ``reverse_bytes=true`` to ``pmbus_read_string()`` for those; + spec compliant chips pass false. + +References +---------- + +* Linux PMBus core: ``linux/drivers/hwmon/pmbus/pmbus_core.c``, + decoder reference; ignore the hwmon publication and caching layers. +* Linux PMBus header: ``linux/drivers/hwmon/pmbus/pmbus.h``; API + surface reference; many constants and the ``struct + pmbus_driver_info`` shape are mirrored verbatim into U-Boot's + ``include/pmbus.h``. +* Linux DT bindings: + ``linux/Documentation/devicetree/bindings/hwmon/pmbus/``. diff --git a/doc/develop/pytest/usage.rst b/doc/develop/pytest/usage.rst index 6002244d608..a9b8b8bd610 100644 --- a/doc/develop/pytest/usage.rst +++ b/doc/develop/pytest/usage.rst @@ -411,7 +411,7 @@ The board can be switched off now. Examples '''''''' -https://source.denx.de/u-boot/u-boot-test-hooks contains some working example hook +https://git.u-boot-project.org/u-boot/u-boot-test-hooks contains some working example hook scripts, and may be useful as a reference when implementing hook scripts for your platform. These scripts are not considered part of U-Boot itself. diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst index 1e3e179d77f..ee77e8827df 100644 --- a/doc/develop/release_cycle.rst +++ b/doc/develop/release_cycle.rst @@ -1,4 +1,4 @@ -.. |next_ver| replace:: v2026.07 +.. |next_ver| replace:: v2026.10 Release Cycle ============= @@ -53,15 +53,15 @@ Examples:: Current Status -------------- -* U-Boot v2026.04 was released on Monday, 06 April 2026. +* U-Boot v2026.07 was released on Monday, 06 July 2026. -* The Merge Window for the next release (|next_ver|) is **closed** with the -rc1 - release on Monday, 27 April 2026. +* The Merge Window for the next release (|next_ver|) is **open** until the -rc1 + release on Monday, 27 July 2026. -* The next branch is now **open** with the -rc2 release on Monday, 11 - May 2026. +* The next branch is now **closed** until the -rc2 release on Monday, 10 + August 2026. -* Release "|next_ver|" is scheduled for Monday, 06 July 2026. +* Release "|next_ver|" is scheduled for Monday, 05 October 2026. Future Releases --------------- @@ -69,36 +69,38 @@ Future Releases .. The following commented out dates are for when release candidates are planned to be tagged. -For the next scheduled release, release candidates were made on: +.. For the next scheduled release, release candidates were made on: -* U-Boot |next_ver|-rc1 was released on Mon 27 April 2026. +.. * U-Boot |next_ver|-rc1 was released on Mon 27 July 2026. -* U-Boot |next_ver|-rc2 was released on Mon 11 May 2026. +.. * U-Boot |next_ver|-rc2 was released on Mon 10 August 2026. -* U-Boot |next_ver|-rc3 was released on Mon 25 May 2026. +.. * U-Boot |next_ver|-rc3 was released on Mon 24 August 2026. -* U-Boot |next_ver|-rc4 was released on Mon 08 June 2026. +.. * U-Boot |next_ver|-rc4 was released on Mon 07 September 2026. -.. * U-Boot |next_ver|-rc5 was released on Mon 22 June 2026. +.. * U-Boot |next_ver|-rc5 was released on Mon 21 September 2026. Please note that the following dates are planned only and may be deviated from as needed. -* "v2026.07": end of MW = Mon, Apr 27, 2026; release = Mon, Jul 06, 2026 - * "v2026.10": end of MW = Mon, Jul 27, 2026; release = Mon, Oct 05, 2026 * "v2027.01": end of MW = Mon, Oct 26, 2026; release = Mon, Jan 04, 2027 * "v2027.04": end of MW = Mon, Jan 25, 2027; release = Mon, Apr 05, 2027 +* "v2027.07": end of MW = Mon, Apr 26, 2027; release = Mon, Jul 05, 2027 + Previous Releases ----------------- Note: these statistics are generated by our fork of `gitdm -<https://source.denx.de/u-boot/gitdm>`_, which was originally created by +<https://git.u-boot-project.org/u-boot/gitdm>`_, which was originally created by Jonathan Corbet. +* :doc:`statistics/u-boot-stats-v2026.07` which was released on 06 July 2026. + * :doc:`statistics/u-boot-stats-v2026.04` which was released on 06 April 2026. * :doc:`statistics/u-boot-stats-v2026.01` which was released on 05 January 2026. diff --git a/doc/develop/security.rst b/doc/develop/security.rst index 84b130646f3..ed652ec756e 100644 --- a/doc/develop/security.rst +++ b/doc/develop/security.rst @@ -11,7 +11,7 @@ Contact ------- The preferred initial point of contact is to send email to -`[email protected]` and use `scripts/get_maintainers.pl` to also include any +`[email protected]` and use `scripts/get_maintainers.pl` to also include any relevant custodians. In addition, Tom Rini should be contacted at diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst index e29fa175727..8172dc55183 100644 --- a/doc/develop/sending_patches.rst +++ b/doc/develop/sending_patches.rst @@ -5,7 +5,7 @@ Sending patches *Before you begin* to implement any new ideas or concepts it is always a good idea to present your plans on the `U-Boot mailing list -<https://lists.denx.de/listinfo/u-boot>`_. U-Boot supports a huge amount of +<https://lists.u-boot-project.org/listinfo/u-boot>`_. U-Boot supports a huge amount of very different systems, and it is often impossible for the individual developer to oversee the consequences of a specific change to all architectures. Discussing concepts early can help you to avoid spending effort on code which, @@ -17,20 +17,77 @@ A good introduction how to prepare for submitting patches can be found in the LWN article `How to Get Your Change Into the Linux Kernel <http://lwn.net/Articles/139918/>`_ as the same rules apply to U-Boot, too. +.. _b4_contrib: + +Using b4 +-------- + +Use the `b4 <https://b4.docs.kernel.org/en/latest/>`__ tool to prepare and send +your patches. b4 has become the preferred tool to sending patches for many Linux +kernel contributors, and U-Boot ships with a ready-to-use ``.b4-config`` that +targets ``[email protected]`` and integrates with ``scripts/get_maintainer.pl`` +for recipient discovery. + +Start a topical series with ``b4 prep`` and keep the commits organised with +``git rebase -i``. ``b4 prep --edit-cover`` opens an editor for the cover letter, +while ``b4 prep --auto-to-cc`` collects reviewers and maintainers from both the +configuration file and ``scripts/get_maintainer.pl``. + +.. code-block:: bash + + b4 prep -n mmc-fixes + git rebase -i origin/master + b4 prep --edit-cover + b4 prep --auto-to-cc + +Run the style checks before sending. ``b4 prep --check`` wraps the existing +tooling so you see the output from ``scripts/checkpatch.pl`` alongside b4's own +validation. You can always invoke ``scripts/checkpatch.pl`` directly for +additional runs. + +.. code-block:: bash + + b4 prep --check + +When the series is ready, use ``b4 send``. Begin with ``--dry-run`` to review the +generated emails and ``--reflect`` to copy yourself for records before +dispatching to ``[email protected]``. + +.. code-block:: bash + + b4 send --dry-run + b4 send --reflect + b4 send + +After reviews arrive, collect Acked-by/Tested-by tags with ``b4 trailers -u`` and +fold them into your commits before resending the updated series. + +.. code-block:: bash + + b4 trailers -u + git rebase -i origin/master + b4 send + Using patman ------------ You can use a tool called patman to prepare, check and send patches. It creates change logs, cover letters and patch notes. It also simplifies the process of -sending multiple versions of a series. +sending multiple versions of a series. patman is driven by tags in your commit +messages, and can collect Reviewed-by and other tags from patchwork when you +send a new version. It can optionally keep a local database of all your series, +tracking each version and their review / applied status over time, so you can +easily track upstreaming progress. -See more details at :doc:`patman`. +patman now lives outside the U-Boot tree; install it with +``pip install patch-manager``. See the +`patman documentation <https://deinde.dev/patman>`_ for details. General Patch Submission Rules ------------------------------ -* All patches must be sent to the `[email protected] - <https://lists.denx.de/listinfo/u-boot>`_ mailing list. +* All patches must be sent to the `[email protected] + <https://lists.u-boot-project.org/listinfo/u-boot>`_ mailing list. * If your patch affects the code maintained by one of the :ref:`custodians`, CC them when emailing your patch. The easiest way to make sure you don't forget @@ -77,7 +134,7 @@ General Patch Submission Rules patches is by using the ``git format-patch`` command. For a patch that is fixing a bug or regression of some sort, please use the ``master`` branch of the mainline U-Boot git repository located at - https://source.denx.de/u-boot/u-boot.git as reference. For new features, if + https://git.u-boot-project.org/u-boot/u-boot.git as reference. For new features, if the ``next`` branch has been opened (which happens with the release of ``-rc2``) that branch should be used, otherwise ``master`` is acceptable. @@ -88,7 +145,7 @@ General Patch Submission Rules If you believe you need to use a mailing list for testing (instead of any regular mail address you own), we have a special test list for such purposes. It would be best to subscribe to the list for the duration of your tests to - avoid repeated moderation - see https://lists.denx.de/listinfo/test + avoid repeated moderation - see https://lists.u-boot-project.org/listinfo/test * Choose a meaningful Subject: - keep in mind that the Subject will also be visible as headline of your commit message. Make sure the subject does not diff --git a/doc/develop/statistics/u-boot-stats-v2026.07.rst b/doc/develop/statistics/u-boot-stats-v2026.07.rst new file mode 100644 index 00000000000..724419a444a --- /dev/null +++ b/doc/develop/statistics/u-boot-stats-v2026.07.rst @@ -0,0 +1,884 @@ +:orphan: + +Release Statistics for U-Boot v2026.07 +====================================== + +* Processed 1328 changesets from 212 developers + +* 25 employers found + +* A total of 255173 lines added, 91237 removed (delta 163936) + +.. table:: Developers with the most changesets + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + David Lechner 139 (10.5%) + Tom Rini 96 (7.2%) + Simon Glass 94 (7.1%) + Marek Vasut 72 (5.4%) + Peng Fan 56 (4.2%) + Heinrich Schuchardt 42 (3.2%) + Julien Stephan 32 (2.4%) + Michal Simek 27 (2.0%) + Jonas Karlman 24 (1.8%) + Dario Binacchi 19 (1.4%) + Ye Li 17 (1.3%) + Quentin Schulz 16 (1.2%) + Mikhail Kshevetskiy 15 (1.1%) + Svyatoslav Ryhel 15 (1.1%) + Francois Berder 14 (1.1%) + Raymond Mao 13 (1.0%) + Neha Malcom Francis 12 (0.9%) + Janne Grunau 12 (0.9%) + Kory Maincent 12 (0.9%) + Richard Genoud 12 (0.9%) + Casey Connolly 11 (0.8%) + Emanuele Ghidoli 11 (0.8%) + Rasmus Villemoes 11 (0.8%) + Francesco Dolcini 11 (0.8%) + Balaji Selvanathan 11 (0.8%) + Alice Guo 10 (0.8%) + Michael Walle 10 (0.8%) + Hrushikesh Salunke 10 (0.8%) + Sparsh Kumar 10 (0.8%) + Luca Weiss 9 (0.7%) + Vincent Stehlé 9 (0.7%) + Johan Jonker 9 (0.7%) + Pranav Tilak 9 (0.7%) + Angelo Dureghello 9 (0.7%) + Alexey Charkov 8 (0.6%) + Aswin Murugan 8 (0.6%) + Torsten Duwe 8 (0.6%) + Patrice Chotard 8 (0.6%) + Mathew McBride 8 (0.6%) + Varadarajan Narayanan 8 (0.6%) + Max Merchel 8 (0.6%) + Christian Marangi 8 (0.6%) + Alexander Feilke 7 (0.5%) + Chris-QJ Chen 7 (0.5%) + Hal Feng 7 (0.5%) + Javier Martinez Canillas 7 (0.5%) + Heiko Schocher 6 (0.5%) + Markus Schneider-Pargmann (TI) 6 (0.5%) + Noah.Shen 6 (0.5%) + Pranav Sanwal 6 (0.5%) + Padmarao Begari 6 (0.5%) + Dan Carpenter 6 (0.5%) + Wojciech Dubowik 6 (0.5%) + Rafał Miłecki 6 (0.5%) + Brian Ruley 6 (0.5%) + Tanmay Kathpalia 5 (0.4%) + Wadim Egorov 5 (0.4%) + Franz Schnyder 5 (0.4%) + Jamie Gibbons 5 (0.4%) + Prashant Kamble 5 (0.4%) + Anshul Dalal 5 (0.4%) + Ludwig Nussel 5 (0.4%) + E Shattow 5 (0.4%) + Adrian Freihofer 5 (0.4%) + Aristo Chen 4 (0.3%) + Shiji Yang 4 (0.3%) + Christian DREHER 4 (0.3%) + Randolph Sapp 4 (0.3%) + Andre Przywara 4 (0.3%) + Ferass El Hafidi 4 (0.3%) + Daniel Palmer 4 (0.3%) + Chunguang Li 4 (0.3%) + Paresh Bhagat 4 (0.3%) + Ion Agorria 4 (0.3%) + Niko Mauno 4 (0.3%) + Vignesh Raghavendra 4 (0.3%) + Neil Armstrong 3 (0.2%) + Sam Day 3 (0.2%) + Denis Mukhin 3 (0.2%) + Sumit Garg 3 (0.2%) + Christian Pötzsch 3 (0.2%) + Lucien.Jheng 3 (0.2%) + Siddharth Vadapalli 3 (0.2%) + Paul HENRYS 3 (0.2%) + Vitor Soares 3 (0.2%) + Michele Bisogno 3 (0.2%) + Primoz Fiser 3 (0.2%) + Sam Shih 3 (0.2%) + Ssunk 3 (0.2%) + Ngo Luong Thanh Tra 3 (0.2%) + Ioana Ciornei 3 (0.2%) + Markus Niebel 3 (0.2%) + Jonas Schwöbel 3 (0.2%) + Lukas Stockmann 3 (0.2%) + Brian Sune 3 (0.2%) + Alif Zakuan Yuslaimi 3 (0.2%) + Ilias Apalodimas 2 (0.2%) + Peter Robinson 2 (0.2%) + João Marcos Costa 2 (0.2%) + Mateusz Furdyna 2 (0.2%) + Zixun LI 2 (0.2%) + Gurumoorthy Santhakumar 2 (0.2%) + Francesco Valla 2 (0.2%) + Yann Gautier 2 (0.2%) + Peter Collingbourne 2 (0.2%) + Vincent Jardin 2 (0.2%) + Ernest Van Hoecke 2 (0.2%) + Weijie Gao 2 (0.2%) + Shiva Tripathi 2 (0.2%) + Paul Kocialkowski 2 (0.2%) + Macpaul Lin 2 (0.2%) + Gregor Herburger 2 (0.2%) + Philip Molloy 2 (0.2%) + Simona Toaca 2 (0.2%) + Flaviu Nistor 2 (0.2%) + Chen Huei Lok 2 (0.2%) + Jeffrey Yu 2 (0.2%) + Sean Anderson 2 (0.2%) + Paul Gerber 2 (0.2%) + Boon Khai Ng 2 (0.2%) + Kavin Gunasekara 2 (0.2%) + Fabio Estevam 2 (0.2%) + Shantur Rathore 2 (0.2%) + Dominik Haller 2 (0.2%) + Bo-Chen Chen 2 (0.2%) + Finley Xiao 2 (0.2%) + Walter Schweizer 2 (0.2%) + Julien Masson 2 (0.2%) + Dinesh Maniyam 2 (0.2%) + Vagrant Cascadian 2 (0.2%) + Mattijs Korpershoek 1 (0.1%) + Andrew Goodbody 1 (0.1%) + Quentin Strydom 1 (0.1%) + Piyush Paliwal 1 (0.1%) + Heiko Stuebner 1 (0.1%) + Colin Pinnell McAllister 1 (0.1%) + Petr Hodina 1 (0.1%) + Udit Kumar 1 (0.1%) + Federico Amedeo Izzo 1 (0.1%) + Frank Böwingloh 1 (0.1%) + Frieder Schrempf 1 (0.1%) + Andrea della Porta 1 (0.1%) + Giovanni Santini 1 (0.1%) + Tony Dinh 1 (0.1%) + Nguyen Tran 1 (0.1%) + Jan Čermák 1 (0.1%) + Lionel Debieve 1 (0.1%) + Liel Harel 1 (0.1%) + Suhaas Joshi 1 (0.1%) + Moteen Shah 1 (0.1%) + Harsimran Singh Tungal 1 (0.1%) + Mark Kettenis 1 (0.1%) + Tze Yee Ng 1 (0.1%) + Raphaël Gallais-Pou 1 (0.1%) + Austin Shirley 1 (0.1%) + Alexander Sverdlin 1 (0.1%) + Brad Klingerman 1 (0.1%) + Charles Perry 1 (0.1%) + Sebastian Josue Alba Vives 1 (0.1%) + Julian Braha 1 (0.1%) + yan wang 1 (0.1%) + Johannes Krottmayer 1 (0.1%) + Yixun Lan 1 (0.1%) + Jernej Skrabec 1 (0.1%) + Lukas Schmid 1 (0.1%) + Chanhong Jung 1 (0.1%) + Christoph Niedermaier 1 (0.1%) + Meiker Gao 1 (0.1%) + ht.lin 1 (0.1%) + Maximilian Brune 1 (0.1%) + Ajit Singh 1 (0.1%) + Antony Kurniawan Soemardi 1 (0.1%) + Eugen Hristev 1 (0.1%) + Levi Shafter 1 (0.1%) + Michael Zimmermann 1 (0.1%) + Rafał Hibner 1 (0.1%) + Kuan-Wei Chiu 1 (0.1%) + Nora Schiffer 1 (0.1%) + Philippe Reynes 1 (0.1%) + Michael Opdenacker 1 (0.1%) + Matwey V. Kornilov 1 (0.1%) + Hugo Villeneuve 1 (0.1%) + Javier Viguera 1 (0.1%) + Kamlesh Gurudasani 1 (0.1%) + Cathy Xu 1 (0.1%) + Neil Berkman 1 (0.1%) + Tomas Alvarez Vanoli 1 (0.1%) + Krzysztof Kozlowski 1 (0.1%) + Javen Xu 1 (0.1%) + Miquel Raynal 1 (0.1%) + Manorit Chawdhry 1 (0.1%) + Ozan Durgut 1 (0.1%) + Abbarapu Venkatesh Yadav 1 (0.1%) + Han Xu 1 (0.1%) + Irving-CH Lin 1 (0.1%) + Caleb Ethridge 1 (0.1%) + Anton Moryakov 1 (0.1%) + Nikita Shubin 1 (0.1%) + Anurag Dutta 1 (0.1%) + Dimitrios Siganos 1 (0.1%) + Tommy Shih 1 (0.1%) + Nick Hu 1 (0.1%) + Andreas Schwab 1 (0.1%) + Ye Zhang 1 (0.1%) + Xuhui Lin 1 (0.1%) + Martin Schwan 1 (0.1%) + Sébastien Szymanski 1 (0.1%) + Ronald Wahl 1 (0.1%) + Christoph Reiter 1 (0.1%) + Jean-Marie Verdun 1 (0.1%) + Tien Fong Chee 1 (0.1%) + Naresh Kumar Ravulapalli 1 (0.1%) + ==================================== ===== + + +.. table:: Developers with the most changed lines + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Tom Rini 147099 (48.3%) + Marek Vasut 20546 (6.8%) + Simon Glass 18934 (6.2%) + Neha Malcom Francis 18915 (6.2%) + David Lechner 10414 (3.4%) + Johan Jonker 7693 (2.5%) + Peng Fan 7101 (2.3%) + Chris-QJ Chen 5103 (1.7%) + Christian Marangi 3770 (1.2%) + Michael Walle 3248 (1.1%) + Brian Sune 3146 (1.0%) + Janne Grunau 2820 (0.9%) + Primoz Fiser 2644 (0.9%) + Ernest Van Hoecke 2485 (0.8%) + Emanuele Ghidoli 2468 (0.8%) + Bo-Chen Chen 2457 (0.8%) + Finley Xiao 2132 (0.7%) + Raymond Mao 2119 (0.7%) + Alice Guo 2052 (0.7%) + Paresh Bhagat 2012 (0.7%) + Sparsh Kumar 1680 (0.6%) + Julien Masson 1589 (0.5%) + Ye Li 1554 (0.5%) + Kory Maincent 1483 (0.5%) + Dan Carpenter 1470 (0.5%) + Franz Schnyder 1460 (0.5%) + Alexander Feilke 1412 (0.5%) + Quentin Schulz 1278 (0.4%) + Balaji Selvanathan 1217 (0.4%) + Cathy Xu 1125 (0.4%) + Dario Binacchi 1094 (0.4%) + Julien Stephan 1066 (0.4%) + Jonas Karlman 1025 (0.3%) + Nguyen Tran 1012 (0.3%) + Andreas Schwab 997 (0.3%) + Brian Ruley 984 (0.3%) + Lucien.Jheng 790 (0.3%) + Heinrich Schuchardt 739 (0.2%) + Tommy Shih 647 (0.2%) + Svyatoslav Ryhel 641 (0.2%) + Torsten Duwe 591 (0.2%) + Irving-CH Lin 580 (0.2%) + Aswin Murugan 578 (0.2%) + Hrushikesh Salunke 562 (0.2%) + Richard Genoud 547 (0.2%) + Casey Connolly 538 (0.2%) + Luca Weiss 518 (0.2%) + Michal Simek 499 (0.2%) + Mathew McBride 474 (0.2%) + Ye Zhang 473 (0.2%) + Pranav Sanwal 439 (0.1%) + Markus Niebel 384 (0.1%) + Jamie Gibbons 347 (0.1%) + Rasmus Villemoes 343 (0.1%) + Max Merchel 332 (0.1%) + Varadarajan Narayanan 303 (0.1%) + Alexey Charkov 268 (0.1%) + Padmarao Begari 255 (0.1%) + Wojciech Dubowik 249 (0.1%) + Tanmay Kathpalia 216 (0.1%) + Tien Fong Chee 216 (0.1%) + Shantur Rathore 208 (0.1%) + Paul Gerber 206 (0.1%) + Mikhail Kshevetskiy 186 (0.1%) + Markus Schneider-Pargmann (TI) 177 (0.1%) + Francesco Dolcini 171 (0.1%) + Vincent Stehlé 165 (0.1%) + Tze Yee Ng 156 (0.1%) + Anshul Dalal 136 (0.0%) + Javier Martinez Canillas 129 (0.0%) + Noah.Shen 128 (0.0%) + Adrian Freihofer 121 (0.0%) + Sean Anderson 120 (0.0%) + Martin Schwan 114 (0.0%) + Heiko Schocher 112 (0.0%) + Pranav Tilak 111 (0.0%) + Christian Pötzsch 105 (0.0%) + Miquel Raynal 101 (0.0%) + Paul HENRYS 96 (0.0%) + Mateusz Furdyna 92 (0.0%) + Shiva Tripathi 88 (0.0%) + Andre Przywara 85 (0.0%) + Johannes Krottmayer 84 (0.0%) + Angelo Dureghello 78 (0.0%) + Niko Mauno 78 (0.0%) + Christian DREHER 74 (0.0%) + Hal Feng 73 (0.0%) + Daniel Palmer 72 (0.0%) + Randolph Sapp 69 (0.0%) + Francois Berder 68 (0.0%) + Ion Agorria 67 (0.0%) + Lukas Stockmann 59 (0.0%) + Paul Kocialkowski 59 (0.0%) + Michele Bisogno 58 (0.0%) + Federico Amedeo Izzo 56 (0.0%) + Philip Molloy 54 (0.0%) + Sumit Garg 53 (0.0%) + Manorit Chawdhry 50 (0.0%) + E Shattow 49 (0.0%) + Chunguang Li 48 (0.0%) + Peter Collingbourne 48 (0.0%) + Alif Zakuan Yuslaimi 47 (0.0%) + Ngo Luong Thanh Tra 45 (0.0%) + Prashant Kamble 41 (0.0%) + Dinesh Maniyam 40 (0.0%) + Gregor Herburger 38 (0.0%) + Jonas Schwöbel 36 (0.0%) + Ioana Ciornei 34 (0.0%) + Rafał Miłecki 33 (0.0%) + Ssunk 29 (0.0%) + Jeffrey Yu 26 (0.0%) + Vitor Soares 25 (0.0%) + Vincent Jardin 25 (0.0%) + Patrice Chotard 23 (0.0%) + Aristo Chen 23 (0.0%) + Wadim Egorov 22 (0.0%) + Siddharth Vadapalli 22 (0.0%) + Sam Shih 22 (0.0%) + Weijie Gao 22 (0.0%) + Neil Armstrong 21 (0.0%) + Suhaas Joshi 21 (0.0%) + Eugen Hristev 21 (0.0%) + Ozan Durgut 21 (0.0%) + Nora Schiffer 20 (0.0%) + Shiji Yang 19 (0.0%) + Zixun LI 19 (0.0%) + Krzysztof Kozlowski 19 (0.0%) + Christoph Reiter 19 (0.0%) + João Marcos Costa 18 (0.0%) + Boon Khai Ng 17 (0.0%) + Ludwig Nussel 15 (0.0%) + Vignesh Raghavendra 15 (0.0%) + Macpaul Lin 15 (0.0%) + Meiker Gao 14 (0.0%) + Kavin Gunasekara 13 (0.0%) + Dominik Haller 12 (0.0%) + Austin Shirley 12 (0.0%) + Ferass El Hafidi 11 (0.0%) + Charles Perry 11 (0.0%) + Chanhong Jung 11 (0.0%) + Sam Day 10 (0.0%) + Yann Gautier 10 (0.0%) + Udit Kumar 10 (0.0%) + yan wang 10 (0.0%) + Dimitrios Siganos 10 (0.0%) + Nick Hu 10 (0.0%) + Denis Mukhin 9 (0.0%) + Walter Schweizer 9 (0.0%) + Christoph Niedermaier 8 (0.0%) + Javier Viguera 8 (0.0%) + Neil Berkman 8 (0.0%) + Piyush Paliwal 7 (0.0%) + Abbarapu Venkatesh Yadav 7 (0.0%) + Peter Robinson 6 (0.0%) + Gurumoorthy Santhakumar 6 (0.0%) + Flaviu Nistor 6 (0.0%) + Yixun Lan 6 (0.0%) + Hugo Villeneuve 6 (0.0%) + Kamlesh Gurudasani 6 (0.0%) + Fabio Estevam 5 (0.0%) + Mattijs Korpershoek 5 (0.0%) + Colin Pinnell McAllister 5 (0.0%) + Raphaël Gallais-Pou 5 (0.0%) + Alexander Sverdlin 5 (0.0%) + Antony Kurniawan Soemardi 5 (0.0%) + Anurag Dutta 5 (0.0%) + Ilias Apalodimas 4 (0.0%) + Andrew Goodbody 4 (0.0%) + Liel Harel 4 (0.0%) + Sebastian Josue Alba Vives 4 (0.0%) + Jean-Marie Verdun 4 (0.0%) + Simona Toaca 3 (0.0%) + Chen Huei Lok 3 (0.0%) + Jan Čermák 3 (0.0%) + Harsimran Singh Tungal 3 (0.0%) + Kuan-Wei Chiu 3 (0.0%) + Han Xu 3 (0.0%) + Caleb Ethridge 3 (0.0%) + Anton Moryakov 3 (0.0%) + Francesco Valla 2 (0.0%) + Vagrant Cascadian 2 (0.0%) + Ajit Singh 2 (0.0%) + Levi Shafter 2 (0.0%) + Michael Zimmermann 2 (0.0%) + Matwey V. Kornilov 2 (0.0%) + Nikita Shubin 2 (0.0%) + Quentin Strydom 1 (0.0%) + Heiko Stuebner 1 (0.0%) + Petr Hodina 1 (0.0%) + Frank Böwingloh 1 (0.0%) + Frieder Schrempf 1 (0.0%) + Andrea della Porta 1 (0.0%) + Giovanni Santini 1 (0.0%) + Tony Dinh 1 (0.0%) + Lionel Debieve 1 (0.0%) + Moteen Shah 1 (0.0%) + Mark Kettenis 1 (0.0%) + Brad Klingerman 1 (0.0%) + Julian Braha 1 (0.0%) + Jernej Skrabec 1 (0.0%) + Lukas Schmid 1 (0.0%) + ht.lin 1 (0.0%) + Maximilian Brune 1 (0.0%) + Rafał Hibner 1 (0.0%) + Philippe Reynes 1 (0.0%) + Michael Opdenacker 1 (0.0%) + Tomas Alvarez Vanoli 1 (0.0%) + Javen Xu 1 (0.0%) + Xuhui Lin 1 (0.0%) + Sébastien Szymanski 1 (0.0%) + Ronald Wahl 1 (0.0%) + Naresh Kumar Ravulapalli 1 (0.0%) + ==================================== ===== + + +.. table:: Developers with the most lines removed + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Simon Glass 16011 (17.5%) + Johan Jonker 7611 (8.3%) + Michael Walle 2998 (3.3%) + Janne Grunau 2599 (2.8%) + Ernest Van Hoecke 2348 (2.6%) + Franz Schnyder 1428 (1.6%) + Andreas Schwab 981 (1.1%) + Quentin Schulz 936 (1.0%) + Mathew McBride 319 (0.3%) + Francesco Dolcini 141 (0.2%) + Max Merchel 135 (0.1%) + Svyatoslav Ryhel 115 (0.1%) + Tanmay Kathpalia 101 (0.1%) + Zixun LI 18 (0.0%) + Aristo Chen 16 (0.0%) + Lukas Stockmann 15 (0.0%) + Weijie Gao 14 (0.0%) + Meiker Gao 14 (0.0%) + Wadim Egorov 12 (0.0%) + Rafał Miłecki 11 (0.0%) + João Marcos Costa 11 (0.0%) + Nick Hu 10 (0.0%) + Javier Viguera 7 (0.0%) + Siddharth Vadapalli 6 (0.0%) + Chanhong Jung 5 (0.0%) + Alexander Sverdlin 1 (0.0%) + ==================================== ===== + + +.. table:: Developers with the most signoffs (total 321) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Peng Fan 59 (18.4%) + David Lechner 45 (14.0%) + Casey Connolly 40 (12.5%) + Michal Simek 26 (8.1%) + Neil Armstrong 20 (6.2%) + Siddharth Vadapalli 10 (3.1%) + Mattijs Korpershoek 10 (3.1%) + Ilias Apalodimas 9 (2.8%) + Alice Guo 8 (2.5%) + Max Merchel 7 (2.2%) + Svyatoslav Ryhel 7 (2.2%) + Heiko Schocher 7 (2.2%) + Heiko Stuebner 4 (1.2%) + Macpaul Lin 4 (1.2%) + Anshul Dalal 4 (1.2%) + Jonas Karlman 4 (1.2%) + Ye Li 4 (1.2%) + Tom Rini 4 (1.2%) + Weijie Gao 3 (0.9%) + Walter Schweizer 3 (0.9%) + Adam Lackorzynski 2 (0.6%) + Meet Patel 2 (0.6%) + Shawn Guo 2 (0.6%) + Udit Kumar 2 (0.6%) + Julien Stephan 2 (0.6%) + Marek Vasut 2 (0.6%) + Simon Glass 1 (0.3%) + Michael Walle 1 (0.3%) + Ernest Van Hoecke 1 (0.3%) + Francesco Dolcini 1 (0.3%) + ht.lin 1 (0.3%) + AngeloGioacchino Del Regno 1 (0.3%) + Jerome Forissier 1 (0.3%) + Huy Bui 1 (0.3%) + Patrick Delaunay 1 (0.3%) + Keerthy 1 (0.3%) + Takuma Fujiwara 1 (0.3%) + Steffen Doster 1 (0.3%) + John Toomey 1 (0.3%) + Harini Katakam 1 (0.3%) + Venkatesh Yadav Abbarapu 1 (0.3%) + Mahammed Sadik Shaik 1 (0.3%) + Jimmy Ho 1 (0.3%) + Elaine Zhang 1 (0.3%) + Chen Huei Lok 1 (0.3%) + Yann Gautier 1 (0.3%) + Sumit Garg 1 (0.3%) + Andre Przywara 1 (0.3%) + Alexey Charkov 1 (0.3%) + Aswin Murugan 1 (0.3%) + Torsten Duwe 1 (0.3%) + Heinrich Schuchardt 1 (0.3%) + Balaji Selvanathan 1 (0.3%) + Alexander Feilke 1 (0.3%) + Paresh Bhagat 1 (0.3%) + Bo-Chen Chen 1 (0.3%) + Brian Sune 1 (0.3%) + ==================================== ===== + + +.. table:: Developers with the most reviews (total 791) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Julien Stephan 100 (12.6%) + Simon Glass 90 (11.4%) + Tom Rini 53 (6.7%) + Peng Fan 50 (6.3%) + Ilias Apalodimas 46 (5.8%) + Kever Yang 41 (5.2%) + Macpaul Lin 34 (4.3%) + Neil Armstrong 33 (4.2%) + Quentin Schulz 33 (4.2%) + Marek Vasut 24 (3.0%) + Sumit Garg 23 (2.9%) + Heinrich Schuchardt 22 (2.8%) + Mattijs Korpershoek 17 (2.1%) + Jerome Forissier 17 (2.1%) + Patrice Chotard 16 (2.0%) + Casey Connolly 15 (1.9%) + Peter Robinson 14 (1.8%) + Tien Fong Chee 11 (1.4%) + Heiko Schocher 9 (1.1%) + Leo Yu-Chi Liang 8 (1.0%) + Varadarajan Narayanan 8 (1.0%) + Francesco Dolcini 7 (0.9%) + João Marcos Costa 7 (0.9%) + Miquel Raynal 7 (0.9%) + Udit Kumar 6 (0.8%) + Anshul Dalal 5 (0.6%) + Andre Przywara 5 (0.6%) + Conor Dooley 5 (0.6%) + Paul Kocialkowski 5 (0.6%) + Raymond Mao 4 (0.5%) + Neha Malcom Francis 4 (0.5%) + Jonas Karlman 3 (0.4%) + Alexander Sverdlin 3 (0.4%) + Michael Trimarchi 3 (0.4%) + Greg Malysa 3 (0.4%) + E Shattow 3 (0.4%) + Kory Maincent 3 (0.4%) + Patrick Delaunay 2 (0.3%) + Jernej Skrabec 2 (0.3%) + Matthias Brugger 2 (0.3%) + Stefan Roese 2 (0.3%) + Yannic Moog 2 (0.3%) + Teresa Remmet 2 (0.3%) + Bryan Brattlof 2 (0.3%) + David Zang 2 (0.3%) + Raphaël Gallais-Pou 2 (0.3%) + Hal Feng 2 (0.3%) + Rasmus Villemoes 2 (0.3%) + Svyatoslav Ryhel 1 (0.1%) + Weijie Gao 1 (0.1%) + AngeloGioacchino Del Regno 1 (0.1%) + Manorit Chawdhry 1 (0.1%) + Kuan-Wei Chiu 1 (0.1%) + Thomas Petazzoni 1 (0.1%) + Andy Shevchenko 1 (0.1%) + Romain Naour 1 (0.1%) + Sebastian Reichel 1 (0.1%) + Bin Meng 1 (0.1%) + Ivan T. Ivanov 1 (0.1%) + Manikandan Muralidharan 1 (0.1%) + Javier Tia 1 (0.1%) + Alexander Dahl 1 (0.1%) + Dhruva Gole 1 (0.1%) + Christian Taedcke 1 (0.1%) + Wolfgang Wallner 1 (0.1%) + Linus Walleij 1 (0.1%) + Daniel Schwierzeck 1 (0.1%) + Tianrui Wei 1 (0.1%) + Shawn Lin 1 (0.1%) + Christopher Obbard 1 (0.1%) + Benjamin Hahn 1 (0.1%) + Radhey Shyam Pandey 1 (0.1%) + Tomas Melin 1 (0.1%) + Frieder Schrempf 1 (0.1%) + Tony Dinh 1 (0.1%) + Sam Day 1 (0.1%) + Sean Anderson 1 (0.1%) + Markus Schneider-Pargmann (TI) 1 (0.1%) + Lucien.Jheng 1 (0.1%) + Primoz Fiser 1 (0.1%) + ==================================== ===== + + +.. table:: Developers with the most test credits (total 94) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Julien Stephan 21 (22.3%) + Pedro Falcato 9 (9.6%) + Ilias Apalodimas 7 (7.4%) + Michal Simek 7 (7.4%) + Udit Kumar 6 (6.4%) + Anshul Dalal 6 (6.4%) + Dario Binacchi 6 (6.4%) + Wei Lu 4 (4.3%) + Aaron Griffith 4 (4.3%) + Neil Armstrong 3 (3.2%) + Peter Robinson 2 (2.1%) + Yannic Moog 2 (2.1%) + Quentin Schulz 1 (1.1%) + Marek Vasut 1 (1.1%) + Heinrich Schuchardt 1 (1.1%) + Mattijs Korpershoek 1 (1.1%) + Francesco Dolcini 1 (1.1%) + Andre Przywara 1 (1.1%) + Weijie Gao 1 (1.1%) + Kuan-Wei Chiu 1 (1.1%) + Wolfgang Wallner 1 (1.1%) + Ernest Van Hoecke 1 (1.1%) + Alexey Charkov 1 (1.1%) + Stefan Bosch 1 (1.1%) + Sughosh Ganu 1 (1.1%) + Ferass El Hafidi 1 (1.1%) + Angelo Dureghello 1 (1.1%) + Padmarao Begari 1 (1.1%) + Emanuele Ghidoli 1 (1.1%) + ==================================== ===== + + +.. table:: Developers who gave the most tested-by credits (total 94) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + David Lechner 21 (22.3%) + Raymond Mao 12 (12.8%) + Torsten Duwe 8 (8.5%) + Kory Maincent 7 (7.4%) + Neha Malcom Francis 6 (6.4%) + Ye Li 5 (5.3%) + Peng Fan 4 (4.3%) + Rasmus Villemoes 4 (4.3%) + Jonas Karlman 3 (3.2%) + Michal Simek 2 (2.1%) + Heinrich Schuchardt 2 (2.1%) + Simon Glass 2 (2.1%) + Siddharth Vadapalli 2 (2.1%) + Shantur Rathore 2 (2.1%) + Neil Armstrong 1 (1.1%) + Quentin Schulz 1 (1.1%) + Marek Vasut 1 (1.1%) + Sam Day 1 (1.1%) + ht.lin 1 (1.1%) + Wadim Egorov 1 (1.1%) + Andrea della Porta 1 (1.1%) + Xuhui Lin 1 (1.1%) + Liel Harel 1 (1.1%) + Abbarapu Venkatesh Yadav 1 (1.1%) + Ngo Luong Thanh Tra 1 (1.1%) + Francois Berder 1 (1.1%) + Daniel Palmer 1 (1.1%) + Ye Zhang 1 (1.1%) + ==================================== ===== + + +.. table:: Developers with the most report credits (total 15) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Simon Glass 3 (20.0%) + Julien Stephan 1 (6.7%) + Weijie Gao 1 (6.7%) + Tom Rini 1 (6.7%) + Yann Gautier 1 (6.7%) + Franz Schnyder 1 (6.7%) + Rudy Andram 1 (6.7%) + Mariusz Madej 1 (6.7%) + Anas Cherni 1 (6.7%) + Philippe Simons 1 (6.7%) + Yuya Hamamachi 1 (6.7%) + Christoph Niedermaier 1 (6.7%) + Suhaas Joshi 1 (6.7%) + ==================================== ===== + + +.. table:: Developers who gave the most report credits (total 15) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + David Lechner 3 (20.0%) + Heinrich Schuchardt 3 (20.0%) + Marek Vasut 2 (13.3%) + Rasmus Villemoes 1 (6.7%) + Michal Simek 1 (6.7%) + Quentin Schulz 1 (6.7%) + Anshul Dalal 1 (6.7%) + Patrice Chotard 1 (6.7%) + Jernej Skrabec 1 (6.7%) + Mateusz Furdyna 1 (6.7%) + ==================================== ===== + + +.. table:: Top changeset contributors by employer + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + (Unknown) 506 (38.1%) + BayLibre SAS 179 (13.5%) + Canonical 98 (7.4%) + Konsulko Group 96 (7.2%) + NXP 93 (7.0%) + Renesas Electronics 64 (4.8%) + Texas Instruments 60 (4.5%) + AMD 48 (3.6%) + Toradex 32 (2.4%) + Bootlin 27 (2.0%) + Linaro 23 (1.7%) + Amarula Solutions 19 (1.4%) + ARM 16 (1.2%) + Siemens 16 (1.2%) + ST Microelectronics 11 (0.8%) + SUSE 10 (0.8%) + Phytec 8 (0.6%) + Red Hat 7 (0.5%) + Rockchip 4 (0.3%) + Analog Devices 3 (0.2%) + Debian.org 2 (0.2%) + linutronix 2 (0.2%) + Nokia 2 (0.2%) + Digi International 1 (0.1%) + Gentoo 1 (0.1%) + ==================================== ===== + + +.. table:: Top lines changed by employer + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Konsulko Group 147099 (48.3%) + (Unknown) 52846 (17.4%) + Texas Instruments 23592 (7.8%) + Renesas Electronics 19393 (6.4%) + Canonical 18957 (6.2%) + BayLibre SAS 13246 (4.4%) + NXP 10795 (3.5%) + Toradex 6609 (2.2%) + Rockchip 2606 (0.9%) + Bootlin 2149 (0.7%) + Linaro 2037 (0.7%) + SUSE 1589 (0.5%) + AMD 1304 (0.4%) + Amarula Solutions 1094 (0.4%) + ARM 266 (0.1%) + Siemens 209 (0.1%) + Phytec 148 (0.0%) + Red Hat 129 (0.0%) + Nokia 92 (0.0%) + Analog Devices 57 (0.0%) + linutronix 38 (0.0%) + ST Microelectronics 34 (0.0%) + Digi International 8 (0.0%) + Gentoo 6 (0.0%) + Debian.org 2 (0.0%) + ==================================== ===== + + +.. table:: Employers with the most signoffs (total 321) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + NXP 71 (22.1%) + Linaro 69 (21.5%) + (Unknown) 62 (19.3%) + BayLibre SAS 47 (14.6%) + AMD 29 (9.0%) + Texas Instruments 20 (6.2%) + Konsulko Group 4 (1.2%) + ARM 4 (1.2%) + Renesas Electronics 3 (0.9%) + Siemens 3 (0.9%) + Canonical 2 (0.6%) + Toradex 2 (0.6%) + ST Microelectronics 2 (0.6%) + Rockchip 1 (0.3%) + SUSE 1 (0.3%) + Collabora Ltd. 1 (0.3%) + ==================================== ===== + + +.. table:: Employers with the most hackers (total 213) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + (Unknown) 134 (62.9%) + Texas Instruments 15 (7.0%) + NXP 7 (3.3%) + Linaro 5 (2.3%) + Siemens 5 (2.3%) + Toradex 5 (2.3%) + BayLibre SAS 4 (1.9%) + AMD 4 (1.9%) + ARM 4 (1.9%) + Bootlin 4 (1.9%) + ST Microelectronics 3 (1.4%) + Rockchip 3 (1.4%) + SUSE 3 (1.4%) + Phytec 3 (1.4%) + Renesas Electronics 2 (0.9%) + Canonical 2 (0.9%) + Analog Devices 2 (0.9%) + Konsulko Group 1 (0.5%) + Amarula Solutions 1 (0.5%) + Red Hat 1 (0.5%) + Nokia 1 (0.5%) + linutronix 1 (0.5%) + Digi International 1 (0.5%) + Gentoo 1 (0.5%) + Debian.org 1 (0.5%) + ==================================== ===== diff --git a/doc/develop/testing.rst b/doc/develop/testing.rst index 3a2b496fa00..1d19b49e82c 100644 --- a/doc/develop/testing.rst +++ b/doc/develop/testing.rst @@ -22,7 +22,7 @@ the quick ones, type this:: make qcheck -It is also possible to run just the tests for tools (patman, binman, etc.). +It is also possible to run just the tests for tools (binman, buildman, etc.). Such tests are included with those tools, i.e. no actual U-Boot unit tests are run. Type this:: |