Re: [PATCH 4/4] target/core: add unknown data direction flag to target_submit_cmd()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2012-01-10 at 14:17 +0100, Sebastian Andrzej Siewior wrote:
> The UASP protocol does not inform the target device upfront in which
> direction the data is moved. This lookup table was created by looking up
> the most used commands in source tree. The .*_IN and .*_OUT are assumed
> to work according to their suffix. SERVICE_ACTION_IN was the only one
> used in testing.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> ---
>  drivers/target/target_core_transport.c |   57 ++++++++++++++++++++++++++++++++
>  include/target/target_core_base.h      |    1 +
>  2 files changed, 58 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
> index 72aca8a..4736814 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -1641,6 +1641,57 @@ int transport_handle_cdb_direct(
>  }
>  EXPORT_SYMBOL(transport_handle_cdb_direct);
>  
> +static int transport_get_cmd_dir(const unsigned char *cdb)
> +{
> +	int ret;
> +
> +	switch (cdb[0]) {
> +	case READ_6:
> +	case READ_10:
> +	case READ_12:
> +	case READ_16:
> +	case INQUIRY:
> +	case MODE_SENSE:
> +	case MODE_SENSE_10:
> +	case SERVICE_ACTION_IN:
> +	case MAINTENANCE_IN:
> +	case PERSISTENT_RESERVE_IN:
> +	case SECURITY_PROTOCOL_IN:
> +	case ACCESS_CONTROL_IN:
> +	case REPORT_LUNS:
> +	case READ_BLOCK_LIMITS:
> +	case READ_POSITION:
> +	case READ_CAPACITY:
> +	case READ_TOC:
> +		ret = DMA_FROM_DEVICE;
> +		break;
> +
> +	case WRITE_6:
> +	case WRITE_10:
> +	case WRITE_12:
> +	case WRITE_16:
> +	case MODE_SELECT:
> +	case MODE_SELECT_10:
> +	case PERSISTENT_RESERVE_OUT:
> +	case MAINTENANCE_OUT:
> +	case SECURITY_PROTOCOL_OUT:
> +	case ACCESS_CONTROL_OUT:
> +		ret = DMA_TO_DEVICE;
> +		break;
> +
> +	case TEST_UNIT_READY:
> +	case SYNCHRONIZE_CACHE:
> +	case START_STOP:
> +		ret = DMA_NONE;
> +		break;
> +	default:
> +		pr_warn("target: Unknown data direction for SCSI Opcode "
> +				"0x%02x\n", cdb[0]);
> +		ret = -EINVAL;
> +	}
> +	return ret;
> +}
> +
>  /**
>   * target_submit_cmd - lookup unpacked lun and submit uninitialized se_cmd
>   *
> @@ -1668,6 +1719,12 @@ int target_submit_cmd(struct se_cmd *se_cmd, struct se_session *se_sess,
>  	BUG_ON(!se_tpg);
>  	BUG_ON(se_cmd->se_tfo || se_cmd->se_sess);
>  	BUG_ON(in_interrupt());
> +
> +	if (flags & TARGET_SCF_UNKNOWN_DIR) {
> +		data_dir = transport_get_cmd_dir(cdb);
> +		if (data_dir < 0)
> +			return data_dir;
> +	}
>  	/*
>  	 * Initialize se_cmd for target operation.  From this point
>  	 * exceptions are handled by sending exception status via

Is there another fabric module case where we are actually ever going to
use this flag..?  If not, it should probably stay in UASP code and pass
the expected data_dir into target_submit_cmd() instead of doing the
extra re-assignment of a parameter here.


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


[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux