Skip to contentSkip to conversation

MS/MS Pro driver for Winbond 528 PCI reader for public review

Winbond dezheng shen 2 participants 2 messages Jun 27, 2006 – Jul 28, 2006 SCSI

lore
Share & tools
lore

dezheng shen

author
#0 lore raw

Dear all:
This email was originally posted on linux-kernel but I didn't get any
response yet so that I post it to this linux-scsi again. Hope that we can get reply soon.

thank you,

dz

Dear all:
Eventually, we found a place to place our sources for public review.

Files are located in

http://zeniv.linux.org.uk/~winbond/

and they have been tested on Intel/AMD single/dual processors and Redhat 9/Fedora 5 and Redhat workstation 4. We ran a stress test on multiple platforms overnight to read/write/format MS/MSPro cards via Winbond 528 readers.

Our customers, motherboard manufactures like ASUS, purchase Winbond
528 then mount their motherboards. Winbond 528 itself provides many reader functions like MS/MSPro/SM/xD/SD/MMC and Winbond also vendors many other different chips for various buses. For example, Winbond 518 is for LPC bus and 488 is for embedded hooked up to data bus directly. Our team is to derive a simple and unified architecture so that we don't have to write redudant codes for each chip, like 518/528/528DA and 488. Another example is, wbtable.c and wbtable.h are also used on xD/SM drivers.

Someone might wonder why we use SCSI subsystem to implement those
device drivers? When we are assigned this job in 2004, the previous engineer has been working on this device driver for over a year and he/she was using SCSI subsystem and we don't know why and we simply follow her/his trace to deliver this driver to our customers as soon as we can. Also, when we plug similar USB flash memory readers, it shows sda/sdb so that we took the same approach as SCSI devices.

Don't hesitate to ask if you have any questions.

best regards,

dz

===========================================================================================
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.

#1 lore raw
Quoted 4 lines · dezheng shen

Dear all:
This email was originally posted on linux-kernel but I didn't get any
response yet so that I post it to this linux-scsi again. Hope that we can get reply soon.

Sorry for the delay, I've been a bit busy with KS/OLS and other things.

This, I'm afraid is basically the killer for scsi:

Quoted 81 lines

static int wb_process_scsi_cmd(Scsi_Cmnd * cmd)

{
	unsigned long flags;
	wb_host_data_t *host_data;
	ENTER();

	host_data = g_wb_host_data;
	wb_chk_valid_medium(host_data);

	wb_unit_ready(cmd);

	switch (cmd->cmnd[0]) {

	case START_STOP:
		WB_PRINTK_SCSI("START_STOP\n");
		wb_scsi_start_stop(cmd);
		break;

	case REQUEST_SENSE:
		WB_PRINTK_SCSI("REQUEST_SENSE\n");
		wb_scsi_request_sense(cmd);
		break;

	case ALLOW_MEDIUM_REMOVAL:
		WB_PRINTK_SCSI("ALLOW_MEDIUM_REMOVAL\n");
		wb_scsi_allow_medium_removal(cmd);
		break;

	case TEST_UNIT_READY:
		WB_PRINTK_SCSI("TEST_UNIT_READY\n");
		wb_scsi_test_unit_ready(cmd);
		break;

	case INQUIRY:
		WB_PRINTK_SCSI("INQUIRY\n");
		wb_scsi_inquiry(cmd);
		break;

	case READ_6:
		WB_PRINTK_ERROR_SCSI("READ_6\n");
		break;

	case READ_10:
		WB_PRINTK_SCSI("READ_10\n");
		wb_scsi_read_wrt(cmd, TRUE);
		break;

	case WRITE_6:
		WB_PRINTK_ERROR_SCSI("WRITE_6\n");
		break;

	case WRITE_10:
		WB_PRINTK_SCSI("WRITE_10\n");
		wb_scsi_read_wrt(cmd, FALSE);
		break;

		// MODE_SENSE is 6-byte command
	case MODE_SENSE:
		WB_PRINTK_SCSI("MODE_SENSE\n");
		wb_scsi_mode_sense(cmd);
		break;

	case READ_CAPACITY:
		WB_PRINTK_SCSI("READ_CAPACITY\n");
		wb_scsi_read_capacity(cmd);
		break;

	case FORMAT_UNIT:
		WB_PRINTK_SCSI("FORMAT_UNIT\n");
		wb_scsi_format_unit(cmd);
		break;

		// haven't handled all necessary cases yet
	default:
		WB_PRINTK_ERROR_SCSI("UNKNOWN command(0x%x)\n", cmd->cmnd[0]);
		wb_make_sense_buffer(cmd, ILLEGAL_REQUEST, 0x20, 0x00);
		cmd->result =
		    WB_CMD_RESULT(DID_OK, COMMAND_COMPLETE, CHECK_CONDITION);
		break;
	}			// end switch
Quoted 7 lines
	spin_lock_irqsave(g_wb_host->host_lock, flags);
	cmd->scsi_done(cmd);
	spin_unlock_irqrestore(g_wb_host->host_lock, flags);

	LEAVE();
	return 0;
}

It means there's no actual SCSI command processor anywhere in the device. You're simply using the SCSI subsystem as a passthrough. We really try to discourage this unless the actual underlying device speaks SCSI. Ideally, a driver like this should fit into the existing mmc/sd subsystem, but if it doesn't, it should be written as a simple block driver rather than doing the unnecessary round trip conversion to SCSI protocols and back.

James