<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers, branch v2026.04-rc1</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/drivers?h=v2026.04-rc1</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/drivers?h=v2026.04-rc1'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2026-01-25T23:29:32Z</updated>
<entry>
<title>power: regulator: enable AWP318W SPL support</title>
<updated>2026-01-25T23:29:32Z</updated>
<author>
<name>Yixun Lan</name>
<email>dlan@gentoo.org</email>
</author>
<published>2026-01-13T04:01:56Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=61c2f29bde1d11a35664525d37c5806e61ec4304'/>
<id>urn:sha1:61c2f29bde1d11a35664525d37c5806e61ec4304</id>
<content type='text'>
Add the descriptions for the DC/DC regulators of the AXP318W, and enable
it when CONFIG_AXP318W_POWER is enabled.

Signed-off-by: Yixun Lan &lt;dlan@gentoo.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</content>
</entry>
<entry>
<title>power: regulator: add AXP318W support</title>
<updated>2026-01-25T23:29:32Z</updated>
<author>
<name>Yixun Lan</name>
<email>dlan@gentoo.org</email>
</author>
<published>2026-01-13T04:01:55Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=71f07932756fa9f414146618c02ed299d565f092'/>
<id>urn:sha1:71f07932756fa9f414146618c02ed299d565f092</id>
<content type='text'>
The PMIC is also known as AXP819 in vendor pmu code

For DCDC6, 8, 9, the underlying hardware support more than two levels
voltage step tuning, but for now only first two levels are implemented
in this driver, hence highest voltage will be limited at seccond level.
It actual meets board requirement in current design, and we've verified
it in Radxa Cubie A7A board.

Following are detail explanation of voltage tuning stpes for those DCDCs:

DCDC | voltage range  | units | steps | implemented
 6   | 0.5   -  1.2   | 10 mV | 71    | Y
 .   | 1.22  -  1.54  | 20 mV | 17    | Y
 .   | 1.8   -  2.4   | 20 mV | 31    | N
 .   | 2.44  -  2.76  | 40 mV | 9     | N
 --------------------------------------------------
 8/9 | 0.5   -  1.2   | 10 mV | 71    | Y
 .   | 1.22  -  1.84  | 20 mV | 32    | Y
 .   | 1.9   -  3.4   | 100mV | 16    | N

Signed-off-by: Yixun Lan &lt;dlan@gentoo.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</content>
</entry>
<entry>
<title>sunxi: extend R528/T113-s3/D1(s) DRAM initialisation</title>
<updated>2026-01-25T23:29:32Z</updated>
<author>
<name>Lukas Schmid</name>
<email>lukas.schmid@netcube.li</email>
</author>
<published>2025-10-26T11:41:17Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d8ee42f113474c81f2d25a98e6cbcd60cf5bdfd5'/>
<id>urn:sha1:d8ee42f113474c81f2d25a98e6cbcd60cf5bdfd5</id>
<content type='text'>
The T113-s4 SoC is using the same die as the T113-s3, but comes with
256MiB of co-packaged DRAM. Besides the doubled size, the DRAM chip
seems to be connected slightly differently, which requires to use a
different pin remapping.

Extend the DRAM initialisation code to add support for the T113-S4 aka
T113M4020DC0 by checking the SoC's CHIPID, which is stored in the first
word of the SID efuses.

Signed-off-by: Lukas Schmid &lt;lukas.schmid@netcube.li&gt;
Tested-by: John Watts &lt;contact@jookia.org&gt;
Reviewed-by: John Watts &lt;contact@jookia.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://source.denx.de/u-boot-usb</title>
<updated>2026-01-25T15:27:34Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-01-25T15:27:34Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=63597329c0350485729e0d39379d3c7b24e0c5ce'/>
<id>urn:sha1:63597329c0350485729e0d39379d3c7b24e0c5ce</id>
<content type='text'>
- XHCI DMA bugfix
</content>
</entry>
<entry>
<title>usb: xhci: fix DMA address corruption in abort_td</title>
<updated>2026-01-25T09:40:42Z</updated>
<author>
<name>ANANDHAKRISHNAN S</name>
<email>anandhakrishnansasidharan@gmail.com</email>
</author>
<published>2026-01-22T05:27:54Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ba94fb3003bd4155284c00c1b37613dd8e284816'/>
<id>urn:sha1:ba94fb3003bd4155284c00c1b37613dd8e284816</id>
<content type='text'>
When aborting a Transfer Descriptor (TD), the xHCI driver updates the
device dequeue pointer by converting the virtual enqueue TRB pointer
into a DMA address.

Previously, the code OR-ed the ring's Dequeue Cycle State (DCS) bit into
the virtual TRB pointer before passing it to xhci_trb_virt_to_dma().
This produced an unaligned virtual address (e.g. ending in 0x...1).

Inside xhci_trb_virt_to_dma(), the offset calculation:

segment_offset = trb - seg-&gt;trbs;

operated on this unaligned pointer, resulting in an incorrect TRB index.
In wraparound cases, this caused the bounds check to fail and the
function to return 0.

As a result, a SET_DEQ_PTR command was issued with a DMA address of 0x0,
leading to controller hangs and transfer timeouts, most commonly when
aborting TDs near the end of a ring segment (e.g. index 63).

Fix this by translating the aligned virtual TRB pointer to a DMA address
first, and only then applying the DCS bit to the resulting physical
address.

Reviewed-by: Marek Vasut &lt;marek.vasut@mailbox.org&gt;
Signed-off-by: ANANDHAKRISHNAN S &lt;anandhakrishnan.s@dicortech.com&gt;
</content>
</entry>
<entry>
<title>video: add DejaVu Mono font</title>
<updated>2026-01-24T16:01:22Z</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2025-11-20T19:34:48Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3a9795581eb7d2c7978802d2d91832ce00e0efe4'/>
<id>urn:sha1:3a9795581eb7d2c7978802d2d91832ce00e0efe4</id>
<content type='text'>
A TrueType font for U-Boot should fulfill the following requirements:

* mono spaced
* support full code page 437
* easily readable

Unfortunately none of the fonts provided with U-Boot fulfills all of these
requirements.

Let's add the DejaVu Mono font. To reduce the code size the characters are
limited to code page 437.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>mmc: Fix retry logic in sd_get_capabilities</title>
<updated>2026-01-22T02:38:50Z</updated>
<author>
<name>Yanir Levin</name>
<email>yanir.levin@tandemg.com</email>
</author>
<published>2026-01-22T02:32:06Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=124aeeff837d20374ec00e292c31444b67b7a971'/>
<id>urn:sha1:124aeeff837d20374ec00e292c31444b67b7a971</id>
<content type='text'>
In sd_get_capabilities an ACMD is sent (SD_CMD_APP_SEND_SCR),
which requires sending APP_CMD (MMC_CMD_APP_CMD) before.

Currently, the ACMD is retried on error, however APP_CMD isn't.
In this case, when the ACMD fails and it is tried again,
the retry attempts will not be handled as ACMD, which is wrong.

The fix performs the retry attempts on the sequence of
APP_CMD and the ACMD together.

Signed-off-by: Yanir Levin &lt;yanir.levin@tandemg.com&gt;
Reviewed-by: Eran Moshe &lt;emoshe@gsitechnology.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-cadence6: Fix the license to GPL-2.0+</title>
<updated>2026-01-22T02:38:49Z</updated>
<author>
<name>Hal Feng</name>
<email>hal.feng@starfivetech.com</email>
</author>
<published>2026-01-12T02:39:47Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0e6ed6117552e6b0ba8675980ef9580fea2ae3ac'/>
<id>urn:sha1:0e6ed6117552e6b0ba8675980ef9580fea2ae3ac</id>
<content type='text'>
The license of the file is not valid. Fix it to GPL-2.0+.

Fixes: fe11aa0b8ca3 ("mmc: sdhci-cadence: Add support for Cadence sdmmc v6")
Reported-by: Quentin Schulz &lt;quentin.schulz@cherry.de&gt;
Reported-by: oliver Fendt &lt;ofendt@googlemail.com&gt;
Closes: https://lore.kernel.org/all/CAFoF8fC4foffYJgYm9CkViET83gDu05noVRxLxgs+KWXN_-LBQ@mail.gmail.com/
Signed-off-by: Hal Feng &lt;hal.feng@starfivetech.com&gt;
Reviewed-by: Quentin Schulz &lt;quentin.schulz@cherry.de&gt;
Reviewed-by: Tanmay Kathpalia &lt;tanmay.kathpalia@altera.com&gt;
Acked-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>mmc: mmc-uclass: Use max-frequency from device tree with driver default fallback</title>
<updated>2026-01-22T02:38:48Z</updated>
<author>
<name>Tanmay Kathpalia</name>
<email>tanmay.kathpalia@altera.com</email>
</author>
<published>2026-01-16T12:50:31Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=efc26685682987e1bea06bd821d7960501326edf'/>
<id>urn:sha1:efc26685682987e1bea06bd821d7960501326edf</id>
<content type='text'>
Use dev_read_u32_default() instead of dev_read_u32() to read the
"max-frequency" property from device tree. This preserves the driver-set
cfg-&gt;f_max value when the optional "max-frequency" property is not
present, ensuring the controller's default frequency is used as fallback
rather than being overwritten.

Suggested-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
Signed-off-by: Tanmay Kathpalia &lt;tanmay.kathpalia@altera.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>power: regulator: common: fix compilation issue</title>
<updated>2026-01-22T02:38:22Z</updated>
<author>
<name>Julien Stephan</name>
<email>jstephan@baylibre.com</email>
</author>
<published>2026-01-15T14:30:45Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dab2c154f605b2f6742aa107dab2b55b9824fdf5'/>
<id>urn:sha1:dab2c154f605b2f6742aa107dab2b55b9824fdf5</id>
<content type='text'>
If CONFIG_DM_GPIO is not enabled, compilation fails with the following
errors:

aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_of_to_plat':
&lt;...&gt;/u-boot/drivers/power/regulator/regulator_common.c:30: undefined reference to `gpio_request_by_name'
aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_get_enable':
&lt;...&gt;/u-boot/drivers/power/regulator/regulator_common.c:57: undefined reference to `dm_gpio_get_value'
aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_set_enable':
&lt;...&gt;/u-boot/drivers/power/regulator/regulator_common.c:92: undefined reference to `dm_gpio_set_value'
make: *** [Makefile:2029: u-boot] Error 139

Since the enable gpio is optional we can conditionally skip these calls.

Reviewed-by: Tanmay Kathpalia &lt;tanmay.kathpalia@altera.com&gt;
Reviewed-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Signed-off-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Reviewed-by: Quentin Schulz &lt;quentin.schulz@cherry.de&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
</feed>
