ips 2/2: minor fixes
Subsystems (3)
PATCH 1/1 ips 2/2: minor fixes
This patch fixes two minor bugs. It allows zero length write commands through to devices. It also prevents the writing of any '\0' characters at the end of version numbers to ips's /proc/scsi files.
David Jeffery
drivers/scsi/ips.c +59 -21
@@ -2160,27 +2160,60 @@copy_info (&info,"\tIRQ number : %d\n" , ha->irq); -if (le32_to_cpu (ha->nvram->signature) ==IPS_NVRAM_P5_SIG ) -copy_info (&info, -"\tBIOS Version : %c%c%c%c%c%c%c%c\n" , - ha->nvram->bios_high[0 ], ha->nvram->bios_high[1 ], - ha->nvram->bios_high[2 ], ha->nvram->bios_high[3 ], - ha->nvram->bios_low[0 ], ha->nvram->bios_low[1 ], - ha->nvram->bios_low[2 ], ha->nvram->bios_low[3 ]); - -copy_info (&info, -"\tFirmware Version : %c%c%c%c%c%c%c%c\n" , - ha->enq->CodeBlkVersion[0 ], ha->enq->CodeBlkVersion[1 ], - ha->enq->CodeBlkVersion[2 ], ha->enq->CodeBlkVersion[3 ], - ha->enq->CodeBlkVersion[4 ], ha->enq->CodeBlkVersion[5 ], - ha->enq->CodeBlkVersion[6 ], ha->enq->CodeBlkVersion[7 ]); - -copy_info (&info, -"\tBoot Block Version : %c%c%c%c%c%c%c%c\n" , - ha->enq->BootBlkVersion[0 ], ha->enq->BootBlkVersion[1 ], - ha->enq->BootBlkVersion[2 ], ha->enq->BootBlkVersion[3 ], - ha->enq->BootBlkVersion[4 ], ha->enq->BootBlkVersion[5 ], - ha->enq->BootBlkVersion[6 ], ha->enq->BootBlkVersion[7 ]); +/* For the Next 3 lines Check for Binary 0 at the end and don't include it if it's there. */ +/* That keeps everything happy for "text" operations on the proc file. */ + +if (le32_to_cpu (ha->nvram->signature) ==IPS_NVRAM_P5_SIG ) { +if (ha->nvram->bios_low[3 ] ==0 ) { +copy_info (&info, +"\tBIOS Version : %c%c%c%c%c%c%c\n" , + ha->nvram->bios_high[0 ], ha->nvram->bios_high[1 ], + ha->nvram->bios_high[2 ], ha->nvram->bios_high[3 ], + ha->nvram->bios_low[0 ], ha->nvram->bios_low[1 ], + ha->nvram->bios_low[2 ]); + + }else { +copy_info (&info, +"\tBIOS Version : %c%c%c%c%c%c%c%c\n" , + ha->nvram->bios_high[0 ], ha->nvram->bios_high[1 ], + ha->nvram->bios_high[2 ], ha->nvram->bios_high[3 ], + ha->nvram->bios_low[0 ], ha->nvram->bios_low[1 ], + ha->nvram->bios_low[2 ], ha->nvram->bios_low[3 ]); + } + + } + +if (ha->enq->CodeBlkVersion[7 ] ==0 ) { +copy_info (&info, +"\tFirmware Version : %c%c%c%c%c%c%c\n" , + ha->enq->CodeBlkVersion[0 ], ha->enq->CodeBlkVersion[1 ], + ha->enq->CodeBlkVersion[2 ], ha->enq->CodeBlkVersion[3 ], + ha->enq->CodeBlkVersion[4 ], ha->enq->CodeBlkVersion[5 ], + ha->enq->CodeBlkVersion[6 ]); + }else { +copy_info (&info, +"\tFirmware Version : %c%c%c%c%c%c%c%c\n" , + ha->enq->CodeBlkVersion[0 ], ha->enq->CodeBlkVersion[1 ], + ha->enq->CodeBlkVersion[2 ], ha->enq->CodeBlkVersion[3 ], + ha->enq->CodeBlkVersion[4 ], ha->enq->CodeBlkVersion[5 ], + ha->enq->CodeBlkVersion[6 ], ha->enq->CodeBlkVersion[7 ]); + } + +if (ha->enq->BootBlkVersion[7 ] ==0 ) { +copy_info (&info, +"\tBoot Block Version : %c%c%c%c%c%c%c\n" , + ha->enq->BootBlkVersion[0 ], ha->enq->BootBlkVersion[1 ], + ha->enq->BootBlkVersion[2 ], ha->enq->BootBlkVersion[3 ], + ha->enq->BootBlkVersion[4 ], ha->enq->BootBlkVersion[5 ], + ha->enq->BootBlkVersion[6 ]); + }else { +copy_info (&info, +"\tBoot Block Version : %c%c%c%c%c%c%c%c\n" , + ha->enq->BootBlkVersion[0 ], ha->enq->BootBlkVersion[1 ], + ha->enq->BootBlkVersion[2 ], ha->enq->BootBlkVersion[3 ], + ha->enq->BootBlkVersion[4 ], ha->enq->BootBlkVersion[5 ], + ha->enq->BootBlkVersion[6 ], ha->enq->BootBlkVersion[7 ]); + }copy_info (&info,"\tDriver Version : %s%s\n" ,IPS_VERSION_HIGH ,IPS_VERSION_LOW );
@@ -2842,6 +2875,11 @@ scb->dcdb.cmd_attribute = ips_command_direction[scb->scsi_cmd->cmnd[0 ]]; +/* Allow a WRITE BUFFER Command to Have no Data */ +/* This is Used by Tape Flash Utilites */ +if ((scb->scsi_cmd->cmnd[0 ] ==WRITE_BUFFER ) && (scb->data_len ==0 )) + scb->dcdb.cmd_attribute =0 ; +if (!(scb->dcdb.cmd_attribute &0x3 )) scb->dcdb.transfer_length =0 ;
Quoted 3 lines · David Jeffery
This patch fixes two minor bugs. It allows zero length write commands through to devices. It also prevents the writing of any '\0' characters at the end of version numbers to ips's
/proc/scsifiles.
I'll take this, but you are thinking about converting the driver away from /proc to sysfs, aren't you?
James
Quoted 4 lines · James Bottomley
I'll take this, but you are thinking about converting the driver away from /proc to sysfs, aren't you?
James
Yes, long term I do. But not in the short term.
Going forward, this driver is intended to cover 2.6 and become the source for future 2.4 driver updates. As support for 2.4 fades, at some point the 2.4 driver will split off and become critical fixes only. Until then, since sysfs doesn't exist in 2.4 I currently plan to keep using proc with a unified driver instead of having to go ahead and split 2.4 and 2.6 and perform dual maintenance.
And I don't think anyone wants to add the sysfs code to a unified driver and then #ifdef in the proc code for 2.4 and #ifdef in the sysfs code for 2.6. That would be the ugliest solution.
In summary, the current plan is to keep using the proc file for the next few releases. Once the 2.4 support goes into hard maintenance mode like the rest of the 2.4 kernel, the plan is to replace the proc code with sysfs.
David Jeffery