From: "Tanya Brokhman" <tlinder@codeaurora.org>
To: 'Matthew Wilcox' <willy@linux.intel.com>,
'Sarah Sharp' <sarah.a.sharp@linux.intel.com>
Cc: linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
ablay@codeaurora.org
Subject: UAS gadget driver & UAS host driver [UPD]
Date: Mon, 7 Mar 2011 10:14:59 +0200 [thread overview]
Message-ID: <000a01cbdc9f$c3cd6600$4b683200$@org> (raw)
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
next reply other threads:[~2011-03-07 8:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-07 8:14 Tanya Brokhman [this message]
2011-04-14 15:21 ` UAS gadget driver & UAS host driver [UPD] Sarah Sharp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000a01cbdc9f$c3cd6600$4b683200$@org' \
--to=tlinder@codeaurora.org \
--cc=ablay@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sarah.a.sharp@linux.intel.com \
--cc=willy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).