On 06/16/2009 04:35 PM, Ramya Desai wrote:
>> This is bulshit. Get your act together babe. You are hacking and deriving from
>> GPLed code. You are legally bind by that.
>>
>> But you are welcome to remove any lowlevel rocket science from your driver
>> and just post the Linux relevant things. Infact why don't you start with a
>> demo driver that just emulates in SW IO transfers close to what your driver
>> will do. scsi_debug is a good place to look.
>>
>>
>> > But Still I am confused with return status (to SCSI layer) for the
>> > command while it is in progress, to get the next command. Is it some
>> > thing like PENDING?
>> >
>>
>>
>> Look in scsi_debug enable some prints. It queues and completes cmnds
>> asynchronously. Look in Alan's other mail I think you are hit with the
>> usb queue_command posting the commands to a thread. This is unique to
>> usb.
>>
>> > -RD
>>
>>
>> Boaz
>>
>
> At this stage, I can not reveal the complete code without my client’s
> permission. But the entire code will be made public (According to GPL)
> once driver is completed.
>
This is counter productive and stupid. If they are going to release the code,
anyway, and there are no secrets, then the time to release it is now when
there are problems. When the driver is done and everything is working we don't
need the code do we? it's during development that the code is important. When there
is nothing to do there is nothing to do.
> But here I am pasting the template structure code that I am using in my driver.
>
> struct scsi_host_template usb_stor_host_template = {
> /* basic userland interface stuff */
> .name = "usb-storage",
> .proc_name = "usb-storage",
> .proc_info = proc_info,
> .info = host_info,
>
> /* command interface -- queued only */
> .queuecommand = queuecommand,
If this is the unchanged queuecommand from usb-storage then
this will not work. As explained
>
> /* error and abort handlers */
> .eh_abort_handler = command_abort,
> .eh_device_reset_handler = device_reset,
> .eh_bus_reset_handler = bus_reset,
All these currently assume a single command how
did you change them?
>
> /* queue commands only, only one command per LUN */
> .can_queue = 5,
> .cmd_per_lun = 5,
>
Good
> /* unknown initiator id */
> .this_id = -1,
>
> .slave_alloc = slave_alloc,
> .slave_configure = slave_configure,
>
> /* lots of sg segments can be handled */
> .sg_tablesize = SG_ALL,
>
> /* limit the total size of a transfer to 120 KB */
> .max_sectors = 240,
>
> /* merge commands... this seems to help performance, but
> * periodically someone should test to see which setting is more
> * optimal.
> */
> .use_clustering = 1,
>
> /* emulated HBA */
> .emulated = 5,
>
> /* we do our own delay after a device or bus reset */
> .skip_settle_delay = 1,
>
> /* sysfs device attributes */
> .sdev_attrs = sysfs_device_attr_list,
>
> /* module management */
> .module = THIS_MODULE
> };
>
>
> Here I am giving some portion of the data structure us_data I am using
>
> struct us_data {
>
> .......
>
> /* SCSI interfaces */
> struct scsi_cmnd *srb[5]; /* current srb */
> unsigned int tag[5]; /* current dCBWTag */
>
> ...continued.
>
> }
>
> If I call void (*done)(struct scsi_cmnd *) call back immediately after
> receiving a command, will I get another command ?
>
I think you miss understood:
done() can/usually be called asynchronously when you have results, good/bad,
of the executed command, and all memory has been consumed, (can be freed).
scsi will call .queuecommand upto min(can_queue, .cmd_per_lun) times
without any call to done(). Then for each done() called it will call
.queuecommand again. (If more commands are pending)
So in short min(can_queue, .cmd_per_lun) is the maximum number of
commands queued at the target.
>
> Regards,
> RD
Above is all good. Your are doing something bad else where, which
you don't show us. Knowing the current USB code, then that is certainly
the culprit. Lots of places assume one command and other places behave
synchronously (ie. wait for response).
Free Life
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
