[PATCH 1/1] sg: Remove aha1542 hack

[PATCH 1/1] sg: Remove aha1542 hack

[brking]

Remove a hack in the sg driver that alters the total buffer
length for SG_IO commands to ensure buffers are not odd byte
lengths. This breaks on the ipr driver since it requires the
request_bufflen to equal the length specified in the cdb.
The block layer SG_IO code does not appear to have this hack.

Signed-off-by: Brian King <brking@us.ibm.com>
---

 linux-2.6-bjking1/drivers/scsi/sg.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/scsi/sg.c~sg_remove_aha1542_hack drivers/scsi/sg.c
--- linux-2.6/drivers/scsi/sg.c~sg_remove_aha1542_hack	2006-01-17 16:50:16.000000000 -0600
+++ linux-2.6-bjking1/drivers/scsi/sg.c	2006-01-17 16:50:29.000000000 -0600
@@ -2162,7 +2162,7 @@ sg_link_reserve(Sg_fd * sfp, Sg_request 
 
 	srp->res_used = 1;
 	SCSI_LOG_TIMEOUT(4, printk("sg_link_reserve: size=%d\n", size));
-	rem = size = (size + 1) & (~1);	/* round to even for aha1542 */
+	rem = size;
 
 	for (k = 0; k < rsv_schp->k_use_sg; ++k, ++sg) {
 		num = sg->length;
_

Re: [PATCH 1/1] sg: Remove aha1542 hack

[Douglas Gilbert]

brking@us.ibm.com wrote:
> Remove a hack in the sg driver that alters the total buffer
> length for SG_IO commands to ensure buffers are not odd byte
> lengths. This breaks on the ipr driver since it requires the
> request_bufflen to equal the length specified in the cdb.
> The block layer SG_IO code does not appear to have this hack.

Brian,
Yes, that is ok with me. The aha1542 may not be
the only adapter sensitive to odd data transfer
lengths. In the spirit of a pass through we can
let the user round up to even if it is needed.

The _original_ block layer SG_IO code didn't have
a "hack" called error processing either :-)

The ipr driver looking inside the cdb to determine
data transfer length is a dangerous procedure. Does
the ipr driver support vendor specific commands?
Even the ubiquitous INQUIRY cdb is tricky since byte 3
became the upper 8 bits of the allocation length in
SPC-3 (it was reserved before that). So does the
driver interpret it as active depending on the age
of the lu?

Signed-off-by: Douglas Gilbert <dougg@torque.net>

> Signed-off-by: Brian King <brking@us.ibm.com>
> ---
> 
>  linux-2.6-bjking1/drivers/scsi/sg.c |    2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN drivers/scsi/sg.c~sg_remove_aha1542_hack drivers/scsi/sg.c
> --- linux-2.6/drivers/scsi/sg.c~sg_remove_aha1542_hack	2006-01-17 16:50:16.000000000 -0600
> +++ linux-2.6-bjking1/drivers/scsi/sg.c	2006-01-17 16:50:29.000000000 -0600
> @@ -2162,7 +2162,7 @@ sg_link_reserve(Sg_fd * sfp, Sg_request 
>  
>  	srp->res_used = 1;
>  	SCSI_LOG_TIMEOUT(4, printk("sg_link_reserve: size=%d\n", size));
> -	rem = size = (size + 1) & (~1);	/* round to even for aha1542 */
> +	rem = size;
>  
>  	for (k = 0; k < rsv_schp->k_use_sg; ++k, ++sg) {
>  		num = sg->length;
> _
> 

Re: [PATCH 1/1] sg: Remove aha1542 hack

[Brian King]

Douglas Gilbert wrote:
> brking@us.ibm.com wrote:
>> Remove a hack in the sg driver that alters the total buffer
>> length for SG_IO commands to ensure buffers are not odd byte
>> lengths. This breaks on the ipr driver since it requires the
>> request_bufflen to equal the length specified in the cdb.
>> The block layer SG_IO code does not appear to have this hack.
> 
> Brian,
> Yes, that is ok with me. The aha1542 may not be
> the only adapter sensitive to odd data transfer
> lengths. In the spirit of a pass through we can
> let the user round up to even if it is needed.
> 
> The _original_ block layer SG_IO code didn't have
> a "hack" called error processing either :-)
> 
> The ipr driver looking inside the cdb to determine
> data transfer length is a dangerous procedure. Does
> the ipr driver support vendor specific commands?
> Even the ubiquitous INQUIRY cdb is tricky since byte 3
> became the upper 8 bits of the allocation length in
> SPC-3 (it was reserved before that). So does the
> driver interpret it as active depending on the age
> of the lu?

Let me clarify... The ipr driver does not do any cdb
cracking to determine data transfer lengths. The virtual
scsi devices that get reported by the ipr adapter firmware
are the devices that are rather strict about allocation
lengths matching buffer lengths. For regular JBOD attached
disks via ipr, even the adapter firmware avoids cracking
cdbs. Its really only an issue for ipr's disk array devices
and the ipr firmware generated logical scsi device used
by userspace to send configuration commands to the ipr adapter.

Brian

> 
> Signed-off-by: Douglas Gilbert <dougg@torque.net>
> 
>> Signed-off-by: Brian King <brking@us.ibm.com>
>> ---
>>
>>  linux-2.6-bjking1/drivers/scsi/sg.c |    2 +-
>>  1 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff -puN drivers/scsi/sg.c~sg_remove_aha1542_hack drivers/scsi/sg.c
>> --- linux-2.6/drivers/scsi/sg.c~sg_remove_aha1542_hack	2006-01-17 16:50:16.000000000 -0600
>> +++ linux-2.6-bjking1/drivers/scsi/sg.c	2006-01-17 16:50:29.000000000 -0600
>> @@ -2162,7 +2162,7 @@ sg_link_reserve(Sg_fd * sfp, Sg_request 
>>  
>>  	srp->res_used = 1;
>>  	SCSI_LOG_TIMEOUT(4, printk("sg_link_reserve: size=%d\n", size));
>> -	rem = size = (size + 1) & (~1);	/* round to even for aha1542 */
>> +	rem = size;
>>  
>>  	for (k = 0; k < rsv_schp->k_use_sg; ++k, ++sg) {
>>  		num = sg->length;
>> _
>>
> 
> 


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center