On 24/02/2012 12:13, Sebastian Andrzej Siewior wrote:
* Roland Dreier | 2012-02-23 09:54:23 [-0800]:
@@ -522,6 +523,7 @@ struct se_cmd {
/* Used to signal cmd->se_tfo->check_release_cmd() usage per cmd */
unsigned check_release:1;
unsigned cmd_wait_set:1;
+ unsigned unknown_data_length:1;
/* See se_cmd_flags_table */
u32 se_cmd_flags;
u32 se_ordered_id;
why do we need this unknown_data_length member? As far
as I can see from Nic's tree (which has the usb-gadget fabric
driver merged up), the only place it is used is in this one function.
Yes, there is only one user of it.
Why not just do
if (flags& TARGET_SCF_UNKNOWN_SIZE)
cmd->data_length = size;
at the end and avoid the obfuscation? Is there some other
use for this member planned?
I don't think so. The new firewire target can probably deal without it.
Nic did not complain about it. The alternative would be to pass flags
additionally to transport_generic_allocate_tasks() and
transport_generic_cmd_sequencer() to have it here _or_ introduce
SCF_UNKNOWN_SIZE so we can grab this flag from se_cmd_flags. Either way
I'm fine with both ways if you want to get rid of unknown_data_length.
My FireWire target doesn't need it at all - it was a mistake that I used
it - it knows the data size. It may be required for the USB Gadget
target though, which is where the copy & paste mistake came from - I
don't believe the transfer size is known in that target.
HTH,
Chris
--
Chris Boot
bootc@xxxxxxxxx
--
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
