kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Cannot read using USB Skeleton Driver
Date: Fri, 16 Sep 2011 16:31:44 +0200	[thread overview]
Message-ID: <20110916143144.GA32485@kroah.com> (raw)
In-Reply-To: <CAKRE6mtWbPAJ=ecgFsoFpv0hhLEb4jZbryTQDs9VZWoLh1_AYA@mail.gmail.com>

On Fri, Sep 16, 2011 at 04:59:08PM +0530, Felix Varghese wrote:
> > What type of device is this you are wishing to write a driver for?  That
> > will determine the type of interface you need to use, odds are it is not
> > going to be a simple char device.
> 
> The device is a custom USB dongle whose firmware is also under
> development. We are still in the process of deciding what it should
> actually show up as on the linux side but right now, we decided to use
> a character device for simplicity reasons until we have simple two-way
> communication over USB up and running. Since I am writing the firmware
> on the device side too, it had indeed been (and still is) my first
> suspect :). But I checked the code multiple times and now I am
> reasonably sure that I am in fact, doing all that is required to send
> out data properly. Besides, data transfer in the other direction works
> fine. I have registered only one IN and one OUT endpoint apart from
> endpoint 0 and I try to send my data through the IN end-point.

For real simplicity, just use the usb-serial generic interface and you
will get a tty device node created for you that you can read and write
data from.

Just do:
	modprobe usb_serial vendor=0x0000 product=0x0000
with the proper vendor and product ids for your device, then plug it in.

No kernel changes needed at all, just have a pair of bulk in/out
endpoints and all will work automatically for you.

But that interface is slow as there is only one urb in flight at any
point in time, so don't rely on that for anything but basic development
and testing.

> I noticed that after making the wait interruptible, if I hit Ctrl-C
> while we are hanging on a read, the device side shows transfer
> complete. So the device, apparently, thinks the data has been sent
> successfully when we have actually aborted the transfer at the other
> end! Shouldn't this mean that something happens after coming out of
> the wait_for_completion that really makes the transfer happen?

Look at the USB data on the wire to make sure that you really are
sending data properly.

good luck,

greg k-h

  reply	other threads:[~2011-09-16 14:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-15 13:32 Cannot read using USB Skeleton Driver Felix Varghese
2011-09-16  7:01 ` Greg KH
2011-09-16 11:29   ` Felix Varghese
2011-09-16 14:31     ` Greg KH [this message]
2011-09-19  5:43       ` Felix Varghese
2011-09-19 12:38         ` Greg KH
2011-09-19 13:21           ` Felix Varghese
2011-09-19 13:46             ` Greg KH
2011-09-20  3:49               ` Felix Varghese
2011-09-21 13:29                 ` Felix Varghese
2011-09-21 16:00                   ` Greg KH

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=20110916143144.GA32485@kroah.com \
    --to=greg@kroah.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /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).