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

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

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

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.

Re: [Winbond] MS/MS Pro driver for Winbond 528 PCI reader for public review

[James Bottomley]

On Tue, 2006-06-27 at 16:07 +0800, dezheng shen wrote:
> 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:

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