u-boot.git/drivers/scsi, branch next Unnamed repository; edit this file 'description' to name the repository. scsi: Adjust SCSI inquiry command data length 2026-03-16T16:39:26+00:00 Macpaul Lin macpaul.lin@mediatek.com 2026-03-05T10:23:24+00:00 041364141b7daef8318a4b8495cac8570002773f Per the SCSI SPC-4 specification, the standard inquiry data length should not be less than 36 bytes. The current implementation uses 512 bytes, which causes detection failures on some UFS devices (e.g., Longsys) that do not expect a transfer length exceeding the standard inquiry size. Align the default standard inquiry length with the Linux kernel's implementation (see drivers/scsi/scsi_scan.c), which uses 36 bytes as the default. Devices requiring vendor-specific inquiry lengths should be handled through quirk settings in the future. Signed-off-by: ht.lin <ht.lin@mediatek.com> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by: Marek Vasut <marek.vasut@mailbox.org> 
Per the SCSI SPC-4 specification, the standard inquiry data length
should not be less than 36 bytes. The current implementation uses 512
bytes, which causes detection failures on some UFS devices (e.g.,
Longsys) that do not expect a transfer length exceeding the standard
inquiry size.

Align the default standard inquiry length with the Linux kernel's
implementation (see drivers/scsi/scsi_scan.c), which uses 36 bytes as
the default. Devices requiring vendor-specific inquiry lengths should
be handled through quirk settings in the future.

Signed-off-by: ht.lin <ht.lin@mediatek.com>
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
spl: Make UFS available for SPL builds 2026-03-12T08:30:44+00:00 Alexey Charkov alchark@gmail.com 2026-01-20T18:09:02+00:00 c664b4d5f30a704003b97823a5ad6361cb16fbe8 Add minimal infrastructure to build SPL images with support for UFS storage devices. This also pulls in SCSI support and charset functions, which are dependencies of the UFS code. With this, only a fixed offset is supported for loading the next image, which should be specified in CONFIG_SPL_UFS_RAW_U_BOOT_SECTOR as the number of 4096-byte sectors into the UFS block device. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://patch.msgid.link/20260120-rk3576-ufs-v5-1-0edb61b301b7@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> 
Add minimal infrastructure to build SPL images with support for UFS
storage devices. This also pulls in SCSI support and charset functions,
which are dependencies of the UFS code.

With this, only a fixed offset is supported for loading the next image,
which should be specified in CONFIG_SPL_UFS_RAW_U_BOOT_SECTOR as the
number of 4096-byte sectors into the UFS block device.

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://patch.msgid.link/20260120-rk3576-ufs-v5-1-0edb61b301b7@gmail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
drivers: scsi: fix double decrement of block count in 64-bit LBA path 2025-12-22T22:19:39+00:00 Balaji Selvanathan balaji.selvanathan@oss.qualcomm.com 2025-12-22T09:01:05+00:00 c0add0039825fbd40620284c202f7c4569154605 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> 
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>
scsi: Fix the name string memory leak during scsi scan 2025-11-11T17:54:48+00:00 Bin Meng bmeng.cn@gmail.com 2025-11-05T11:07:24+00:00 c6e8befd4b8da4a99c779a0fddd92690e2f611fa There is a memory leak during the scsi scan process due to the strdup'ed name string is never freed. Actually it is unnecessary to pass a strdup'ed name string to blk_create_devicef() as we can use the name string on the stack directly. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
There is a memory leak during the scsi scan process due to the
strdup'ed name string is never freed. Actually it is unnecessary
to pass a strdup'ed name string to blk_create_devicef() as we can
use the name string on the stack directly.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
drivers: scsi: fix inaccurate block count reporting in scsi operations 2025-08-07T17:14:23+00:00 Balaji Selvanathan balaji.selvanathan@oss.qualcomm.com 2025-07-28T16:21:05+00:00 b32dda34506b4f486bc803d0c7251f987edd2455 The 'blks' variable in scsi_read/write/erase functions is updated regardless of pass/fail of the scsi operation . If the scsi operation fails, 'blkcnt' is updated using an incorrect value of 'blks'. This wrong 'blkcnt' is returned to the caller and it assumes all blocks were processed correctly. Fix this by updating the 'blks' variable only if the scsi operation succeeds. Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> 
The 'blks' variable in scsi_read/write/erase functions is updated
regardless of pass/fail of the scsi operation . If the scsi operation
fails, 'blkcnt' is updated using an incorrect value of 'blks'. This
wrong 'blkcnt' is returned to the caller and it assumes all blocks were
processed correctly.

Fix this by updating the 'blks' variable only if the scsi operation
succeeds.

Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
scsi: Make static functions consistent using lbaint_t 2025-07-14T21:16:43+00:00 Andrew Goodbody andrew.goodbody@linaro.org 2025-07-07T14:12:20+00:00 41713b99671f6775c18d70d31ccd8b27e438abe1 The static helper functions are inconsistent in their use of their third parameter which is used to pass a block count. Keep consistency by always using lbaint_t here. This will fix an issue where two left shifts were overflowing the variable type in use. This issue found by Smatch Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> 
The static helper functions are inconsistent in their use of their third
parameter which is used to pass a block count. Keep consistency by
always using lbaint_t here. This will fix an issue where two left shifts
were overflowing the variable type in use.

This issue found by Smatch

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
scsi: Implement get_blk() function 2025-05-30T00:35:49+00:00 Varadarajan Narayanan quic_varada@quicinc.com 2025-05-13T09:17:07+00:00 9a2010941f56929cb28432cc3f4b37a944f55b8e Add a function to obtain the block device for SCSI. Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> Acked-by: Casey Connolly <casey.connolly@linaro.org> 
Add a function to obtain the block device for SCSI.

Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Acked-by: Casey Connolly <casey.connolly@linaro.org>
drivers: scsi: Add 'erase' support 2025-04-11T02:55:53+00:00 Varadarajan Narayanan quic_varada@quicinc.com 2025-04-01T10:09:59+00:00 7dd49a9264a6de349343a873e465e1a5fcd459e3 UFS devices uses the block and scsi frameworks. Enable UFS erase support by adding erase support to SCSI. Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> 
UFS devices uses the block and scsi frameworks. Enable UFS erase
support by adding erase support to SCSI.

Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
scsi: sync cache on write 2025-04-10T20:21:41+00:00 Caleb Connolly caleb.connolly@linaro.org 2025-03-26T12:24:09+00:00 ffe4e6ab42d2534302be825e49a2d085acf80f30 We don't have a mechanism to safely shutdown block devices prior to a baord reset or driver removal. Prevent data loss by synchronizing the SCSI cache after every write. In particular this solves the issue of capsule updates looping on some devices because the board resets immediately after deleting the capsule file and this write wouldn't be flushed in time. This may impact NAND wear, but should be negligible given the usecases for disk write in U-Boot. Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> 
We don't have a mechanism to safely shutdown block devices prior to a
baord reset or driver removal. Prevent data loss by synchronizing the
SCSI cache after every write.

In particular this solves the issue of capsule updates looping on some
devices because the board resets immediately after deleting the capsule
file and this write wouldn't be flushed in time.

This may impact NAND wear, but should be negligible given the usecases
for disk write in U-Boot.

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
scsi: fix typo in setup_read_ext() 2025-04-10T20:21:41+00:00 Caleb Connolly caleb.connolly@linaro.org 2025-03-26T12:24:08+00:00 0cd3c1e7d0201cf9e4dbcac1e0179604f4461062 This clears the 6th byte of cmd twice rather than setting the 9th byte to 0. Fix it. The only other command that sets the 9th byte is the 64-bit read, so this likely never caused issues in practise. Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> 
This clears the 6th byte of cmd twice rather than setting the 9th byte
to 0. Fix it.

The only other command that sets the 9th byte is the 64-bit read, so
this likely never caused issues in practise.

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>