Re: use_sg != 0 assumption (was Re: [PATCH 5/9] Drop single buffer request support.)

["Kristian Høgsberg" <krh@redhat.com>]

Stefan Richter wrote:
> Kristian Høgsberg wrote:
>> The SCSI layer only passes sg requests down, so drop the
>> use_sg == 0, request_bufflen != 0 case.
>>
>> Signed-off-by: Kristian Hoegsberg <krh@redhat.com>
>> ---
>>  drivers/firewire/fw-sbp2.c |   43 +------------------------------------------
>>  1 files changed, 1 insertions(+), 42 deletions(-)
> 
> [...]
> 
>> @@ -1063,21 +1035,8 @@ static int sbp2_scsi_queuecommand(struct scsi_cmnd *cmd, scsi_done_fn_t done)
>>  		orb->request.misc |=
>>  			COMMAND_ORB_DIRECTION(SBP2_DIRECTION_TO_MEDIA);
>>  
>> -	if (cmd->use_sg) {
>> -		if (sbp2_command_orb_map_scatterlist(orb) < 0)
>> -			goto fail_map_payload;
>> -	} else if (cmd->request_bufflen > SBP2_MAX_SG_ELEMENT_LENGTH) {
>> -		/*
>> -		 * FIXME: Need to split this into a sg list... but
>> -		 * could we get the scsi or blk layer to do that by
>> -		 * reporting our max supported block size?
>> -		 */
>> -		fw_error("command > 64k\n");
>> +	if (cmd->use_sg && sbp2_command_orb_map_scatterlist(orb) < 0)
>>  		goto fail_map_payload;
>> -	} else if (cmd->request_bufflen > 0) {
>> -		if (sbp2_command_orb_map_buffer(orb) < 0)
>> -			goto fail_map_payload;
>> -	}
>>  
>>  	fw_memcpy_to_be32(&orb->request, &orb->request, sizeof orb->request);
>>  
> 
> Would a BUG_ON(cmd->use_sg == 0); be in order?

That's a good idea, though it needs to be

   BUG_ON(cmd->usg_sg == 0 && cmd->request_bufflen > 0);

since commands with no payload have use_sg == 0 and request_bufflen == 0.

Kristian


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html