u-boot.git/drivers, branch v2026.01

clk: scmi: Remove duplicated scmi_generic_protocol_version() request

2026-01-05T02:04:48+00:00

scmi_generic_protocol_version() request is done twice in scmi_clk_probe().
Remove first call which is useless.

Fixes: ae7e0330ce22 ("clk: scmi: add compatibility with clock protocol 2.0")
Reviewed-by: Peng Fan 
Reviewed-by: Marek Vasut 
Signed-off-by: Patrice Chotard 
Signed-off-by: Peng Fan

clk: scmi: Fix priv initialization in scmi_clk_gate()

2026-01-05T02:04:48+00:00

In scmi_clk_probe(), in case of CLK_CCF is not enabled, parent private
data is not set, so in scmi_clk_gate(), an uninitialized priv struct is
retrieved.

SCMI request is performed either using scmi_clk_state_in_v1 or
scmi_clk_state_in_v2 struct depending of the unpredictable value of
priv->version which leads to error during SCMI clock enable.

Issue detected on STM32MP157C-DK2 board using the SCMI device tree
stm32mp157c-dk2-scmi.dts.

Fixes: 0619cb32030b ("firmware: scmi: Add clock v3.2 CONFIG_SET support")
Reviewed-by: Peng Fan 
Reviewed-by: Marek Vasut 
Signed-off-by: Patrice Chotard 
Signed-off-by: Peng Fan

clk: scmi: Fix typo scmi_clk_get_attibute

2026-01-05T02:04:48+00:00

Fix typo attibute, rename scmi_clk_get_attibute() to
scmi_clk_get_attribute().

Reviewed-by: Peng Fan 
Reviewed-by: Marek Vasut 
Signed-off-by: Patrice Chotard 
Signed-off-by: Peng Fan

clk: renesas: Do not disable realtime modules on R8A77995 D3

2025-12-29T19:47:53+00:00

Later versions of the datasheet makes it clear D3 do not have any
realtime module stop control registers (RMSTPCRx). Remove the
manipulation of them from the module clock table to match this.

Suggested-by: Marek Vasut 
Signed-off-by: Niklas Söderlund

clk: renesas: Do not enable MSTP4 extra modules on R8A77995 D3

2025-12-29T19:47:53+00:00

Since commit a2bd99549c61 ("clk: renesas: Tear clock controller down
last before booting OS") enabling the module gated by bit 8 in MSTP4
prevents Linux from booting. The bits 8 and 7 of MSTP4 where only
documented in early versions of the datasheet and have since been
removed.

To allow Linux to boot update the MSTP4 enable value to reflect the
hardware default, 0x80.

Suggested-by: Marek Vasut 
Signed-off-by: Niklas Söderlund

net: ravb: Configure CXR31 and CXR35 on rzg2l

2025-12-23T14:35:34+00:00

As in Linux with d78c0ced60 ("net: ravb: Make write access to CXR35 first
before accessing other EMAC register"), configure CXR31 and CXR35 correctly
on rzg2. MII mode does not work correctly unless those registers are
properly configured.

Signed-off-by: Mathieu Othacehe 
Reviewed-by: Marek Vasut

drivers: scsi: fix double decrement of block count in 64-bit LBA path

2025-12-22T22:19:39+00:00

The scsi_read function incorrectly decrements the block count twice
when handling large disks that trigger the CONFIG_SYS_64BIT_LBA code
path (reads beyond block 268,435,455). The variable 'blks' was being
decremented both inside the 64-bit LBA block and after the successful
scsi_exec() call, causing incorrect block count tracking and data
abort errors on large capacity disks.

Signed-off-by: Balaji Selvanathan 
Tested-by: Tony Dinh

clk: mediatek: remove duplicate '@parent' field doc

2025-12-16T17:14:31+00:00

Remove duplicate '@parent' field documentation in struct mtk_composite.
There is no need to say the same thing twice.

Also fix spelling mistake in the word "parent" while we're at it.

Signed-off-by: David Lechner

rockchip: i2c: fix illegal I2C START/STOP condition

2025-12-13T16:02:10+00:00

In the last message sent in rockchip_i2c_xfer, the controller is
disabled (see rk_i2c_disable() in rk_i2c_read()/rk_i2c_write()), then
the STOP condition is sent (see rk_i2c_send_stop_bit() in
rockchip_i2c_xfer()) and the controller is disabled once again (see
rk_i2c_disable() right after).

The issue is that re-enabling the controller just to send the STOP
condition doesn't work. When, the controller is disabled, the SCL and
SDA lanes are not driven anymore and thus enter the idle mode where they
are kept high by the external HW pull-up. To send a STOP condition, one
needs to drive the SDA line so that a rising edge happens while SCL is
high. Experimentally (on PX30 and RK3399), when enabling the controller
to send a STOP condition after it's been disabled, the controller only
drives the SDA line to trigger the rising edge for the STOP condition,
leaving SCL undriven (and thus, high). This means, that because SDA is
high before this happens and that we need a rising edge, the controller
drives the SDA line low and then releases it, meaning we trigger a START
condition followed by a STOP condition:

SCL
_________
_____...
__ _____
_____... \/
SDA
^ STOP
^ START

This is illegal in I2C protocol[1]:

5. A START condition immediately followed by a STOP condition (void
message) is an illegal format. Many devices however are designed to
operate properly under this condition.

My guess is that the I2C controller IP knows that it makes only sense to
send a STOP condition after a START condition, meaning the controller is
already driving the SCL line low and neither the device nor controller
drive the SDA line after the last ACK/NACK as there's no need to, then
it needs to drive SDA, release SCL to make it high and then release the
SDA line. However, after it's been disabled, the SCL is already released
so the controller only essentially drives SDA and then releases it.

It happens that this seems to be breaking the SE050 Secure Element after
a few transfers in the middle of a transfer where it starts clock
stretching the bus forever. It may be related to Errata 3.2[2] but the
description of the setup isn't an exact match to the current situation.

It seems to be required to disable the I2C controller between messages
as the Linux kernel states that "The HW is actually not capable of
REPEATED START. But we can get the intended effect by resetting its
internal state and issuing an ordinary START.". Between messages, this
logic seems fine as I get an Sr (repeated START condition) before
starting the next message in the transfer without a STOP condition.
However, we should NOT disable the controller after the last message in
the transfer otherwise we do this illegal START condition followed by
the STOP condition, hence the added check.

[1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf 3.1.10 The target address and R/W bit point 5
[2] https://www.nxp.com/docs/en/errata/SE050_Erratasheet.pdf

Fixes: c9fca5ec8849 ("rockchip: i2c: don't sent stop bit after each message")
Signed-off-by: Quentin Schulz
Reviewed-by: Heiko Schocher
Reviewed-by: Kever Yang

rockchip: i2c: move ACK comment where it applies

2025-12-13T16:02:10+00:00

The I2C_CON_LASTACK is kind of a misnomer as setting it means sending a
NACK as last byte acknowledge when the controller is in receive mode. It
should therefore be used only when there's no more data to transfer
after this.

Move the comment in the proper if block.

Sync the comment with the Linux kernel's while at it so it's more
explicit.

Fixes: 5deaa530280f ("rockchip: i2c: fix >32 byte reads")
Signed-off-by: Quentin Schulz 
Reviewed-by: Heiko Schocher 
Reviewed-by: Kever Yang