* UAS gadget driver & UAS host driver [UPD]
@ 2011-03-07 8:14 Tanya Brokhman
2011-04-14 15:21 ` Sarah Sharp
0 siblings, 1 reply; 2+ messages in thread
From: Tanya Brokhman @ 2011-03-07 8:14 UTC (permalink / raw)
To: 'Matthew Wilcox', 'Sarah Sharp'
Cc: linux-arm-msm, linux-usb, ablay
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. 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? Why
is this needed?
I'm working with v2.6.37. We don't upgrade our Linux host with each rc that
is released but if you think that there are relevant fixes in the latest
release, please let me know and I'll update our host.
Best regards,
Tanya Brokhman
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: UAS gadget driver & UAS host driver [UPD]
2011-03-07 8:14 UAS gadget driver & UAS host driver [UPD] Tanya Brokhman
@ 2011-04-14 15:21 ` Sarah Sharp
0 siblings, 0 replies; 2+ messages in thread
From: Sarah Sharp @ 2011-04-14 15:21 UTC (permalink / raw)
To: Tanya Brokhman
Cc: 'Matthew Wilcox', linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, ablay-sgV2jX0FEOL9JmXXK+q4OQ
On Mon, Mar 07, 2011 at 10:14:59AM +0200, Tanya Brokhman wrote:
> Hi Matthew, Sarah
Hi Tanya,
> 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. 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'm not too clear on what TMs are, since I'm a USB expert, not a SCSI
expert. Are they a part of some SCSI spec, or the UAS spec, or ?
> 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.
I've queued two patches for the USB core that might help the issue
you've been seeing when your device is reset. Can you test them and see
if they help?
The patches are here:
http://marc.info/?l=linux-usb&m=130274096710742&w=2
http://marc.info/?l=linux-usb&m=130274099910782&w=2
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-04-14 15:21 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-07 8:14 UAS gadget driver & UAS host driver [UPD] Tanya Brokhman
2011-04-14 15:21 ` Sarah Sharp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).