u-boot.git/doc/device-tree-bindings, branch v2025.07 Unnamed repository; edit this file 'description' to name the repository. Merge branch 'nand-next' of https://source.denx.de/u-boot/custodians/u-boot-nand-flash into next 2025-03-17T16:18:18+00:00 Tom Rini trini@konsulko.com 2025-03-17T16:18:18+00:00 4101b56d0bf041336cdda10d63be7acdfc92a61b CI: https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/25178 This merge request add support for cadence raw nand driver for agilex board and add a fix to meson driver. 
CI: https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/25178

This merge request add support for cadence raw nand driver for agilex
board and add a fix to meson driver.
dt: nand: add cadence nand dt-bindings 2025-03-15T09:35:00+00:00 Dinesh Maniyam dinesh.maniyam@intel.com 2025-02-26T16:18:15+00:00 1ae1e9c55ec42d5176aa5f4a88efc62c63863e43 The Cadence NAND is a configurable mtd raw block which supports multiple options for chipsets, clocking and reset structure, and feature list. Signed-off-by: Dinesh Maniyam <dinesh.maniyam@intel.com> 
The Cadence NAND is a configurable mtd raw block which
supports multiple options for chipsets, clocking and reset structure, and
feature list.

Signed-off-by: Dinesh Maniyam <dinesh.maniyam@intel.com>
doc: Add dt-bindings and descriptions for ADI SC5xx-family pinctrl 2025-03-12T16:24:58+00:00 Greg Malysa malysagreg@gmail.com 2025-02-26T17:30:24+00:00 a0ffd8d7cd8efb8b348c07fa18a610a4534f9bea This adds the necessary dt-bindings and documentation to use the ADI SC5xx pinctrl driver in a device tree. It is not yet available upstream in the Linux kernel. Eventually, it will be moved there. Signed-off-by: Vasileios Bimpikas <vasileios.bimpikas@analog.com> Signed-off-by: Utsav Agarwal <utsav.agarwal@analog.com> Signed-off-by: Arturs Artamonovs <arturs.artamonovs@analog.com> Signed-off-by: Greg Malysa <malysagreg@gmail.com> 
This adds the necessary dt-bindings and documentation to use the ADI
SC5xx pinctrl driver in a device tree. It is not yet available upstream
in the Linux kernel. Eventually, it will be moved there.

Signed-off-by: Vasileios Bimpikas <vasileios.bimpikas@analog.com>
Signed-off-by: Utsav Agarwal <utsav.agarwal@analog.com>
Signed-off-by: Arturs Artamonovs <arturs.artamonovs@analog.com>
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
doc: remove redundant leds bindings 2025-02-07T16:53:39+00:00 Heiko Schocher hs@denx.de 2025-01-28T13:52:45+00:00 167bc2cd69f50a5fad6f4f95c5c4d969ea0d80c1 remove file doc/device-tree-bindings/leds/common.txt as we have this now already in dts/upstream/include/dt-bindings/leds/common.h which is imported from linux. Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com> 
remove file doc/device-tree-bindings/leds/common.txt
as we have this now already in
dts/upstream/include/dt-bindings/leds/common.h
which is imported from linux.

Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
usb: dwc2: Add support for Canaan K230 2025-01-16T07:55:27+00:00 Junhui Liu junhui.liu@pigmoral.tech 2025-01-14T16:46:37+00:00 892b31a1fb0b2c857bc31c60d3d0db091901a41a Canaan Kendryte K230 SoC instantiates a dwc2 v4.30a core. This patch adds the compatible for it. Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com> 
Canaan Kendryte K230 SoC instantiates a dwc2 v4.30a core. This patch
adds the compatible for it.

Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
doc: remove redundant Rockchip bindings 2024-12-15T01:05:04+00:00 Johan Jonker jbx6244@gmail.com 2024-11-30T21:18:57+00:00 4888d1bd0ea4e1a9976890ba221e9d14433231eb Most Rockchip device tree related bindings are converted to YAML and available in the U-boot /dts/upstream/Bindings/ directory. Remove all redundant U-boot entries. Signed-off-by: Johan Jonker <jbx6244@gmail.com> 
Most Rockchip device tree related bindings are converted to YAML
and available in the U-boot /dts/upstream/Bindings/ directory.
Remove all redundant U-boot entries.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
i2c: i2c-gpio: add support for i2c-gpio,sda-output-only 2024-10-21T04:32:40+00:00 Alex Shumsky alexthreed@gmail.com 2024-10-15T20:29:31+00:00 f315a4813186ca098a6c698754a06b8297d400f6 Some I2C slave devices are read-only and don't even answer with NACK. For example FD65x segment LED controllers. Make them usable with i2c-gpio,sda-output-only that are already supported by Linux 6.3+. Signed-off-by: Alex Shumsky <alexthreed@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de> 
Some I2C slave devices are read-only and don't even answer with NACK.
For example FD65x segment LED controllers.
Make them usable with i2c-gpio,sda-output-only that are already supported
by Linux 6.3+.

Signed-off-by: Alex Shumsky <alexthreed@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD" 2024-10-11T18:23:25+00:00 Tom Rini trini@konsulko.com 2024-10-11T18:23:25+00:00 47e544f576699ca4630e20448db6a05178960697 Simon Glass <sjg@chromium.org> says: When the SPL build-phase was first created it was designed to solve a particular problem (the need to init SDRAM so that U-Boot proper could be loaded). It has since expanded to become an important part of U-Boot, with three phases now present: TPL, VPL and SPL Due to this history, the term 'SPL' is used to mean both a particular phase (the one before U-Boot proper) and all the non-proper phases. This has become confusing. For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL' phases, not just SPL. So code which can only be compiled for actual SPL, for example, must use something like this: #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) In Makefiles we have similar issues. SPL_ has been used as a variable which expands to either SPL_ or nothing, to chose between options like CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was updated to support 'VPL_' as well. This series starts a change in terminology and usage to resolve the above issues: - The word 'xPL' is used instead of 'SPL' to mean a non-proper build - A new CONFIG_XPL_BUILD define indicates that the current build is an 'xPL' build - The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now defined for TPL and VPL phases - The existing SPL_ Makefile variable is renamed to SPL_ - The existing SPL_TPL Makefile variable is renamed to PHASE_ It should be noted that xpl_phase() can generally be used instead of the above CONFIGs without a code-space or run-time penalty. This series does not attempt to convert all of U-Boot to use this new terminology but it makes a start. In particular, renaming spl.h and common/spl seems like a bridge too far at this point. The series is fully bisectable. It has also been checked to ensure there are no code-size changes on any commit. 
Simon Glass <sjg@chromium.org> says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
xpl: Rename spl_phase to xpl_phase_t 2024-10-11T17:44:47+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:35+00:00 41ea75aa00079ff8368fca53267671cee6289415 This name fits better with the new naming scheme, so update it. Signed-off-by: Simon Glass <sjg@chromium.org> 
This name fits better with the new naming scheme, so update it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Merge patch series "arm: Initial support for Analog Devices SC5xx boards" 2024-10-03T15:30:37+00:00 Tom Rini trini@konsulko.com 2024-10-03T15:30:37+00:00 08990e2254ffd63ade7f633b78b6573abc9b7e90 Oliver Gaskell <Oliver.Gaskell@analog.com> says: ADSP-SC5xx is a series of ARM-based DSPs. This comprises the armv7 based SC57x, SC58x and SC594 series, and the armv8 based SC598. This patch series includes configurations, init code, and minimal DTs to enable Analog Devices' evaluation boards for these SoCs to boot through SPL and into U-Boot Proper, as well as devicetree schemas for the added DTs. This patch series depends on ("arm: Add Analog Devices SC5xx Machine Type") (https://lists.denx.de/pipermail/u-boot/2024-April/552043.html) 
Oliver Gaskell <Oliver.Gaskell@analog.com> says:

ADSP-SC5xx is a series of ARM-based DSPs.
This comprises the armv7 based SC57x, SC58x and SC594 series, and the
armv8 based SC598.

This patch series includes configurations, init code, and minimal DTs
to enable Analog Devices' evaluation boards for these SoCs to boot
through SPL and into U-Boot Proper, as well as devicetree schemas for
the added DTs.

This patch series depends on ("arm: Add Analog Devices SC5xx Machine
Type") (https://lists.denx.de/pipermail/u-boot/2024-April/552043.html)