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

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

rockchip: i2c: fix incorrect STOP flag for the interrupt enable register

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

I2C_CON_STOP is a flag to be used for the con register, where it is bit
4 to send the STOP condition.

To enable the interrupt the controller sends to tell it's finished
sending the STOP condition, it's the ien register at bit 5.

Let's use the proper offset.

My hunch is that enabling the interrupt is useless as the interrupt
status register is always up-to-date and enabling the interrupt is just
so that the interrupt is available via the GIC. However, U-Boot has no
interrupt support and the logic was working well before this patch. This
is just so people aren't side-tracked when debugging I2C issues on
Rockchip by checking all writes are proper.

Fixes: 3437469985df ("rockchip: Add I2C driver")
Signed-off-by: Quentin Schulz 
Reviewed-by: Heiko Schocher 
Reviewed-by: Kever Yang

i2c: muxes: i2c_mux_select/deselect() should be static

2025-11-15T06:37:25+00:00

i2c_mux_select/deselect() are not called out of i2c-mux-uclass.c that's why
they should be static.

Signed-off-by: Michal Simek 
Reviewed-by: Heiko Schocher

Merge tag 'qcom-for-2026.01-rc2' of https://source.denx.de/u-boot/custodians/u-boot-snapdragon

2025-10-30T17:06:44+00:00

A variety of Qualcomm features/fixes for this cycle, notably with a few
new platforms gaining support:

* Initial support for SDM670 (similar to SDM845), SM6350, and SM7150
  platforms is added
* USB and UART issues on MSM8916 are addressed (improving stability/
  reliability)
* Firmware loading is implemented for the GENI serial engine, this is
  used on some platforms to load firmware for i2c/spi/uart to work

Some additional patches like binman support for building MBN files still
need some additional work.

CI: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/8ef6ac07b35e39a57501554680bbf452e818d3e3/pipelines?ref=qcom-main

i2c: geni: load firmware if required

2025-10-30T17:04:51+00:00

Load firmware for the peripheral if necessary.

Signed-off-by: Casey Connolly 
Reviewed-by: Neil Armstrong 
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-4-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly

misc: introduce Qcom GENI wrapper

2025-10-30T17:04:51+00:00

Qualcomm peripherals like UART, SPI, I2C, etc are all exposed under a
common GENI Serial Engine wrapper device. Replace the stub driver we use
for this currently with a full-on misc device and implement support for
loading peripheral firmware.

Each of the peripherals has it's own protocol-specific firmware, this is
stored on the internal storage of the device with a well-known partition
type GUID.

To support this, GENI will bind peripherals in two stages. First the
ones that already have firmware loaded (such as the serial port) are
bound in the typical way. But devices that require firmware loading are
deferred until EVT_LAST_STAGE_INIT. At this point we can be sure that
the storage device is available, so we load the firmware and then bind
and probe the remaining children.

Child devices are expected to determine if firmware loading is necessary
and call qcom_geni_load_firmware().

Since Linux currently doesn't support loading firmware (and firmware may
not be available), we probe all GENI peripherals to ensure that they
always load firmware if necessary.

Signed-off-by: Casey Connolly 
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-3-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly

i2c: geni: fix error message wording in clk_disable

2025-10-30T17:04:51+00:00

Correct the error messages so they accurately describe that we failed to
disable the clocks, not to enable them.

Signed-off-by: Casey Connolly 
Reviewed-by: Neil Armstrong 
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-2-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly

i2c: rcar_i2c: Add R-Car Gen5 support

2025-10-28T08:51:02+00:00

Add support for R-Car Gen5 SoCs into the driver.
I2C on R-Car Gen5 is treated the same as Gen3 and Gen4.

Signed-off-by: Minh Le 
Signed-off-by: Hai Pham 
Signed-off-by: Marek Vasut  # Tweak commit message
Reviewed-by: Heiko Schocher

i2c: add support for the MT7621 I2C controller

2025-10-28T08:49:57+00:00

This commit introduces a port of the Linux kernel's driver for the
Mediatek's MT7621 I2C controller.

The port was undertaken as the existing driver intended for Mediatek
I2C controllers (mtk_i2c.c) is not compatible with the MT7621.

To use the driver:

  1.  Ensure that the mode of the i2c pin group is
      configured for "i2c" rather than "gpio".

  2.  Delete the existing (bitbanged) i2c node from
      arch/mips/dts/mt7621.dtsi, or specify:

        /delete-node/ &i2c;

  3.  Declare:

        i2c: i2c@1e000900 {
                compatible = "mediatek,mt7621-i2c";
                reg = <0x1e000900 0x100>;

                clocks = <&clk50m>;
                clock-names = "sys_clock";

                resets = <&rstctrl RST_I2C>;
                reset-names = "i2c_reset";

                pinctrl-names = "default";
                pinctrl-0 = <&i2c_pins>;

                #address-cells = <1>;
                #size-cells = <0>;
                status = "okay";
        };

Signed-off-by: Justin Swartz 
Reviewed-by: Heiko Schocher