Re: UAS gadget driver & UAS host driver [UPD]

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

 



On Mon, 7 Mar 2011, Tanya Brokhman wrote:

> Hi Matthew, Sarah
> 
> We've made some progress with testing our UAS Gadget driver with the UAS
> host. We are now able to read/write files from the device, so the good news
> are that the device is operational. I'll upload the latest version of our
> code during the day for your review. 
> 
> We do have some questions regarding the UAS host driver implementation:
> 
> 1. When the device powers up there is immediately a unit attention condition
> on the LUNs RESET_OCCURED that needs to be cleared/acknowledged by the host
> using the MODE SENSE command.

Don't you mean REQUEST SENSE?  MODE SENSE is very different.

>  So when connecting the device to the host the
> SCSI command issued are:
> 	- Inquiry - succeeds
> 	- Test Unit ready - fails with status = CHECK CONDIFION (0x02) due
> to the RESET_OCCURED unit attention
> 	- Mode sense - according to the LeCroy recording and the dmesg on
> the device side this command is successful but on the host side the error
> handler 
> 	  takes over, tries to reset the device and since the TMs are not
> implemented yet - the enumeration sequence fails. I've added a hack in the
> gadget
> 	  driver that clears the RESET_OCCURED unit attention after power up
> and with this hack the device and the host are operational but it seems to
> me 
> 	  that this should be looked into. I would appreciate your help on
> the matter.
> 2. After the SCSI enumeration completes and the device is idle, I've noticed
> that there is an endless loop of the following SCSI commands:
> 	- test unit ready
> 	- prevent allow medium removal (prevent =1)
> 	- test unit ready
> 	- prevent allow medium removal (prevent =0)
> 	- test unit ready
> 	- prevent allow medium removal (prevent =1)
> 	- etc...
> The device is still operational and this loop is interrupted with read or
> write commands if necessary. Is this correct behavior of the UAS host?

Well, it's not _incorrect_.  :-)

> Why
> is this needed?

The TEST UNIT READY and PREVENT-ALLOW (prevent=1) commands are needed
every time the device file is opened, because the SCSI disk driver
needs to know whether medium is present and needs to prevent the medium
from being removed while the device is open.  Similarly, PREVENT-ALLOW
(prevent=0) is needed every time the device file is closed, so that the 
user _can_ change the medium.

The reason for the endless loop is simple: Your host's desktop 
environment includes a program that polls for medium changes every few 
seconds.  Because it opens the device file each time it polls, you get 
that sequence of SCSI commands.  You may be able to prevent this 
polling by running the hal-disable-polling program.

Alan Stern

--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux