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>

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>

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>

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 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>

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>

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>

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>

The SCSI specification originally required that the second
Command Data Byte contain the LUN value in its high-order bits,
but this field has been marked as reserved since the SCSI-3 spec
from 1996.

Some vendors uses this byte to pass vendor specific data,
and specifying the LUN can trigger strange behaviors.
For the record, this happened on an UFS device where LUN0 was
working perfectly and reading the other LUNs would get the last
buffer data that was read for LUN0, making this issue very very
hard to debug.

It's sane to assume U-Boot will probably never encounter
an SCSI-2 multi-LUN device, if somehow it happens the enquiry
command would need to get the SCSI level to handle this case.

The Linux fix was added in [1] to fix the exact same issue.

[1] https://lore.kernel.org/all/Pine.LNX.4.44L0.1409021108380.2308-100000@iolanthe.rowland.org/

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>

SCSI READ CAPACITY reports the address of the last block and the block
size. The total number of blocks is thus last block address plus one.

This also fixes the corresponding test case.