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 <balaji.selvanathan@oss.qualcomm.com>
Tested-by: Tony Dinh <mibodhi@gmail.com>

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 <dlechner@baylibre.com>

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 <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

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 <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

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 <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Add support for the Renesas MFIS mailbox, which provides an interface
between the different CPU Cores, such as AP System Core domain and the
Realtime Core domain, SCP Core domain and AP System Core domain or
Realtime Core domain and AP System Core domain or Realtime Core domain.

Signed-off-by: Tuyen Dang <tuyen.dang.xa@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Update the driver
[Marek: Rename the driver to renesas-mfis, simplify the driver.
        Always use only one TX channel and no RX channel, drop all
	unnecessary code. Perform 1ms delay in send callback which
	is perfectly fine to do in U-Boot which does RX polling]

The current state of SCP on Renesas R-Car Gen5 is not yet final and
is still missing full clock control, the clock control is exposed as
separate enable/disable and rate controls.

Temporarily introduce custom local compound clock, which are used as
an adaptation layer between U-Boot clock tree and current state of
SCP, and which bind two SCP clock into a single compound clock, which
provides both enable/disable and rate controls.

This is mainly meant to be used by SD/eMMC controller, to allow the
driver to both turn its clock on and off, and also obtain the current
clock rate. This is going to be removed once the SCP clock protocol
solidifies.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

First set of u-boot-at91 fixes for the 2026.01 cycle:

This small fixes set includes a fix on the mtd pmecc driver.

- Assorted updates

This pull request delivers a broad set of improvements across the
SoCFPGA family, including Agilex5, Cyclone V, SoC64, and common code.
Key updates include refined boot flows, new driver enablement, handoff
tooling enhancements, and several stability fixes.

Highlights:

* Agilex5:
  - Enable FAT-based environment storage
  - MMC driver restores legacy clkmgr-based clock lookup
  - Cleanup of MMC raw mode enablement logic

* Cyclone V:
  - SPL FAT boot support and updated bootcmd sequence
  - Disable SPL SPI to prevent contention with FAT-based boot
  - New board handoff script and BSP generator tooling
  - Optimized Makefile support for SoCFPGA handoff workflows* New drivers:
  - Cadence xSPI driver with full protocol and command support
  - SPL enablement for DW APB GPIO controller

* Networking:
  - xgmac MDIO now supports Clause 45 read/write operations

* NAND / SoC64:
  - Enable ONFI detection in Denali NAND controller for SoC64 devices

* DTS and board updates:
  - Sync common SoCFPGA U-Boot DTS with kernel sources
  - Fixes for FPGA2SDRAM configuration and SoCFPGA boot stall behavior
  - Vining_FPGA migrated to the modern LED framework
  - Device tree relocation no longer forced off for Vining FPGA

* Tooling:
  - Introduces a new Python-based Cyclone V BSP generator
    covering EMIF, IOCSR, HPS, XML parsing, rendering, and documentation
    to simplify board enablement and handoff regeneration workflows

Overall, this series improves boot robustness, enhances xSPI and MDIO
capabilities, modernizes board support, and introduces new tooling to
streamline SoCFPGA handoff generation.

Pipelines test passing
https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/28569