u-boot.git/drivers/ata, branch v2025.07

Merge patch series "MIPS: Boston: Various enhancements"

2025-04-22T21:13:21Z

Jiaxun Yang says: This is a huge series which promoted MIPS/Boston target into a usable state, with fixes to drivers and general framework issues I found in this process. I also converted the target to OF_UPSTREAM. This target is covered by QEMU, to test on QEMU: ``` make boston64r6el_defconfig make qemu-system-mips64el -M boston -cpu I6500 -bios ./u-boot.bin -nographic ``` Link: https://lore.kernel.org/r/20240517-boston-v3-0-1ea7d23f4a1d@flygoat.com

ahci: dwc_ahsata: Generalize the driver

2025-04-22T21:08:47Z

Remove hard dependencies to arch headers, get clock from clk subsystem if arch clock function is not available, align compatible strings with devicetree binding. No functional change on existing platforms, just get it build on other platforms. Signed-off-by: Jiaxun Yang

ahci: DMA addressing fixes

2025-04-22T21:08:47Z

Ensure that we are using correct physical/virtual address for DMA buffer write and hardware register settings. The convention is: in ahci_ioports all pointers are virtual, that will be converted to physical address when writing to hardware registers or into sg/cmd_tbl. Also fixed 64bit physical address support for dwc_ahsata, ensure higher bits are written into registers/sg properly. Use memalign for allocating aligned buffer in dwc_ahsata so we don't have to do our own alignment in driver. Signed-off-by: Jiaxun Yang

Merge patch series "Switch to using $(PHASE_) in Makefiles"

2025-04-11T18:16:49Z

Tom Rini says: This series switches to always using $(PHASE_) in Makefiles when building rather than $(PHASE_) or $(XPL_). It also starts on documenting this part of the build, but as a follow-up we need to rename doc/develop/spl.rst and expand on explaining things a bit. Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com

Kbuild: Always use $(PHASE_)

2025-04-11T18:16:44Z

It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our Makefiles as part of the macros to determine when to do something in our Makefiles based on what phase of the build we are in. For consistency, bring this down to a single macro and use "$(PHASE_)" only. Signed-off-by: Tom Rini

Merge patch series "scsi: ensure writes are flushed to disk"

2025-04-10T20:21:46Z

Caleb Connolly says: SCSI devices like UFS may maintain their own cache to speed up writes, however this is lost on board reset (and may be lost on device removal or reset by OS drivers). Currently this can be worked around by "waiting for a while" after writing data to disk, but of course this is not an acceptable solution. Ideally U-Boot would have a mechanism to flush caches during board reset, but until that logic is hooked up let's be sure that all writes are actually propagated to the storage device so that we don't lose data on board reset. The same logic was already implemented just for the AHCI backend, this duplicated logic has been removed and support for the SYNC_CACHE command is added to AHCI. This is particularly noticeable during capsule updates, since the update file is deleted and the board is reset immediately afterwards which resulted in the same capsule update being applied over and over again. This specifically fixes Qualcomm SDM845 devices with UFS 2.1, but likely all UFS devices that use a cache. Link: https://lore.kernel.org/r/20250326-scsi-sync-on-write-v2-0-12ab05bd464b@linaro.org

ata: ahci: implement SCSI_SYNC_CACHE

2025-04-10T20:21:41Z

The SCSI layer now issues a SYNC_CACHE command after every write to ensure there is no data loss due to a board reset after write. Implement support for this command and remove the same logic from the ATA write path to be consistent with other SCSI backends. Ranges are not supported and the whole cache will be flushed in all cases. This was done per iteration in ata_scsiop_read_write(), but it's not clear why this was the case, calling it once for the entire write ought to achieve the same result. Signed-off-by: Caleb Connolly Reviewed-by: Neil Armstrong

ata: ahci: remove bad free

2025-04-08T22:23:27Z

In the case of a memory allocation error, the ahci_port_start() function tries to free the `pp' pointer. This pointer was not dynamically allocated but does in fact point to an element of the port[] array member of the struct ahci_uc_priv. Remove the erroneous call to free() to fix this. Fixes: 4782ac80b02f ("Add AHCI support to u-boot") Signed-off-by: Vincent Stehlé Cc: Tom Rini Cc: Jason Jin Reviewed-by: Andre Przywara

blk: Make block subsystems select BLK

2025-01-21T01:26:54Z

The BLK symbol has a few meanings, one of which is that it controls the driver model portion of a "block device". Rather than having this hidden symbol be "default y if ..." it should be select'd by the various block subsystems. Symbols such as PVBLOCK which already select'd BLK are unchanged". Reviewed-by: Peter Robinson Reviewed-by: Quentin Schulz Signed-off-by: Tom Rini

Merge patch series "Implement ACPI on aarch64"

2024-10-28T00:44:13Z

Patrick Rudolph says: Based on the existing work done by Simon Glass this series adds support for booting aarch64 devices using ACPI only. As first target QEMU SBSA support is added, which relies on ACPI only to boot an OS. As secondary target the Raspberry Pi4 was used, which is broadly available and allows easy testing of the proposed solution. The series is split into ACPI cleanups and code movements, adding Arm specific ACPI tables and finally SoC and mainboard related changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the mandatory ACPI tables are supported, allowing to boot into Linux without errors. The QEMU SBSA support is feature complete and provides the same functionality as the EDK2 implementation. The changes were tested on real hardware as well on QEMU v9.0: qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \ -pflash secure-world.rom \ -pflash unsecure-world.rom qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \ -smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \ -dtb bcm2711-rpi-4-b.dtb -nographic Tested against FWTS V24.03.00. Known issues: - The QEMU rpi4 support is currently limited as it doesn't emulate PCI, USB or ethernet devices! - The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly cache related). - PCI on RPI4 isn't working on real hardware since the pcie_brcmstb Linux kernel module doesn't support ACPI yet. Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com