USB Class MSC SCSI CB Length is wrong for 3 commands

[froha]

Describe the set-up Custom board with USB Host and stm32-mw-usb-host. A Zephyr device with a USB Device with MSC Class with the new USB Stack Next. CONFIG_USB_DEVICE_STACK_NEXT=y

Describe the bug The new Zephyr USB Device Stack checks the length of the SCSI command. The log of the Zephyr RTOS shows following: <err> usbd_msc: Unknown SCSI opcode 0x12 The message is not correct, because the length is wrong for this opcode.

The bug is that the stm32-mw-usb-host sets for all SCSI commands a length of 10. But the following commands has a length of 6:

Opcode: TEST_UNIT_READY Function: USBH_MSC_SCSI_TestUnitReady

Opcode: INQUIRY Function: USBH_MSC_SCSI_Inquiry

Opcode: REQUEST_SENSE Function: USBH_MSC_SCSI_RequestSense

In this functions it should be: MSC_Handle->hbot.cbw.field.CBLength = 6; instead of: MSC_Handle->hbot.cbw.field.CBLength = CBW_LENGTH;

#define CBW_LENGTH 10

For the other 3 commands (READ_CAPACITY10, WRITE10 and READ10) the length of 10 is correct.

How To Reproduce Use a Zephyr RTOS on a board (ST Board) and the Mass Storage example. A board with the stm32-mw-usb-host and MSC Class. For Zephyr RTOS you can enable following to show the error Message: CONFIG_USBD_MSC_LOG_LEVEL_ERR=y

Additional context SCSI commands description for example: https://www.seagate.com/files/staticfiles/support/docs/manual/Interface%20manuals/100293068j.pdf INQUIRY command page 92 REQUEST SENSE command page 195 TEST UNIT READY command page 230

The most software will ignore this problem, but not the new Zephyr USB Stack.

[froha]

additional info: Zephyr source code: https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/usb/device_next/class/usbd_msc_scsi.c

size_t scsi_cmd(struct scsi_ctx *ctx, const uint8_t *cb, int len,
		uint8_t data_in_buf[static CONFIG_USBD_MSC_SCSI_BUFFER_SIZE])
{
	ctx->cmd_is_data_read = false;
	ctx->cmd_is_data_write = false;
	ctx->remaining_data = 0;
	ctx->read_cb = NULL;
	ctx->write_cb = NULL;

#define SCSI_CMD(opcode) do {							\
	if (len == sizeof(SCSI_CMD_STRUCT(opcode)) && cb[0] == opcode) {	\
		LOG_DBG("SCSI " #opcode);					\
		if (GET_CONTROL_NACA(((SCSI_CMD_STRUCT(opcode)*)cb))) {		\
			return illegal_request(ctx, INVALID_FIELD_IN_CDB);	\
		}								\
		return scsi_##opcode(ctx, (SCSI_CMD_STRUCT(opcode)*)cb,		\
				     data_in_buf);				\
	}									\
} while (0)

	SCSI_CMD(TEST_UNIT_READY);
	SCSI_CMD(REQUEST_SENSE);
	SCSI_CMD(INQUIRY);
	SCSI_CMD(MODE_SENSE_6);
	SCSI_CMD(START_STOP_UNIT);
	SCSI_CMD(PREVENT_ALLOW_MEDIUM_REMOVAL);
	SCSI_CMD(READ_FORMAT_CAPACITIES);
	SCSI_CMD(READ_CAPACITY_10);
	SCSI_CMD(READ_10);
	SCSI_CMD(WRITE_10);
	SCSI_CMD(MODE_SENSE_10);

	LOG_ERR("Unknown SCSI opcode 0x%02x", cb[0]);
	return illegal_request(ctx, INVALID_FIELD_IN_CDB);
}

for example the "REQUEST_SENSE" struct with 6 bytes:

SCSI_CMD_STRUCT(REQUEST_SENSE) {
	uint8_t opcode;
	uint8_t desc;
	uint8_t reserved2;
	uint8_t reserved3;
	uint8_t allocation_length;
	uint8_t control;
} __packed;

SCSI commands (Oracle website):

TEST_UNIT_READY https://docs.oracle.com/en/storage/storage-software/acsls/8.5/acsir/test-unit-ready-00h.html

REQUEST_SENSE https://docs.oracle.com/en/storage/storage-software/acsls/8.5/acsir/request-sense-03h.html

INQUIRY https://docs.oracle.com/en/storage/storage-software/acsls/8.5/acsir/inquiry-command-12h.html

[MKISTM]

Hello,

Thank you for the detailed report and for providing the context and references.

You are absolutely right — the CBW Length for certain SCSI commands like TEST_UNIT_READY (0x00), INQUIRY (0x12), and REQUEST_SENSE (0x03) should indeed be set to 6 bytes, not the default 10 bytes defined by CBW_LENGTH and considered as a common value.

The current implementation in the stm32-mw-usb-host stack in usbh_msc_scsi.h file uses a fixed length of 10 for all commands, must be specific for each SCSI command or use two define value: - CBW_LENGTH_6 = 6 byte - CBW_LENGTH_10 = 10 byte

[ALABSTM]

ST Internal Reference: 218157

[ALABSTM]

Hi @froha,

I hope you are doing well. Just to let you know this issue has been fixed in the frame of version 3.5.4, published just now. Thank you for your patience and thank you again for having reported the point.

With regards,