From: "David Lopez" <dave.l.lopez@gmail.com>
To: "Greg KH" <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, linux-usb-devel@lists.sourceforge.net
Subject: Re: [PATCH] USB: add driver for LabJack USB DAQ devices
Date: Sat, 2 Dec 2006 12:51:23 -0700 [thread overview]
Message-ID: <571a92f0612021151r25849c81md2f44e29532c5c73@mail.gmail.com> (raw)
In-Reply-To: <20061202074825.GA15982@kroah.com>
On 12/2/06, Greg KH <greg@kroah.com> wrote:
> On Fri, Dec 01, 2006 at 05:12:56PM -0700, David Lopez wrote:
> > On 12/1/06, Greg KH <greg@kroah.com> wrote:
> > >On Fri, Dec 01, 2006 at 01:37:22PM -0700, David Lopez wrote:
> > >> From: David Lopez <dave.l.lopez@gmail.com>
> > >
> > >> + /* Gets the Product ID for the device */
> > >> + case IOCTL_LJ_GET_PRODUCT_ID:
> > >> + retval = put_user(dev->udev->descriptor.idProduct,
> > >> + (unsigned int __user
> > >*)arg);
> > >> + break;
> > >
> > >You can get this from sysfs or usbfs today. Don't duplicate it please.
> >
> > I didn't look at sysfs or usbfs. I just needed a way to determine the
> > device from a device node in /dev from user space, and it seemed easy
> > to use ioctl.
>
> Ok, but as there are other ways to get this information, can you take it
> out please?
I'll take it out.
> > >> + /* Sets the bulk in endpoint for the next read from an
> > >> integer argument.
> > >> + * There are two bulk endpoints, which are endpoints 0 and
> > >1
> > >> when
> > >> + * setting the integer argument. */
> > >> + case IOCTL_LJ_SET_BULK_IN_ENDPOINT:
> > >> + data = (void __user *) arg;
> > >> + if (data == NULL)
> > >> + break;
> > >> +
> > >> + if (copy_from_user(&ep, data, sizeof(int))) {
> > >> + retval = -EFAULT;
> > >> + break;
> > >> + }
> > >> +
> > >> + if(ep > N_BULK_IN_ENDPOINTS || ep < 0)
> > >> + retval = -EINVAL;
> > >> + else
> > >> + dev->next_bulk_in_endpoint = ep;
> > >> + break;
> > >
> > >Why is this needed?
> >
> > The devices have a stream mode which can only be read from the second
> > bulk in endpoint. All other communications are done from the first
> > bulk in and bulk out endpoints, and I needed some way to indicate that
> > the the next read should be from second bulk in endpoint keeping in
> > mind that first bulk in endpoint can still be used. Is there a better
> > way to do this?
>
> Can you just create a new device node for the second endpoint? That way
> your userspace tools don't have to toggle anything, and it might make
> things for users simpler. Just use the second device node to read from
> the endpoint used for streaming. Writing on it might not need to do
> anything (or you could tie the write into the single out endpoint,
> that's up to you.)
>
> Would that work?
To do this do I call usb_register_dev twice with different endpoint
info in the usb_ljusb struct that I pass in the probe function?
This could work, though it is preferred that the second node's
numbering is +1 of the first. So for example, the first node for the
first set of endpoints would be ljusb0 and second endpoint would be
ljusb1. Though now that I think about it a global mutex should help
with that.
Someone pointed out to me that there is the possibility of using the
libusb library as opposed to having a kernel driver, which would be
preferable. I will need to test this library to see if it what I am
looking for and is stable enough, and if all goes well I might not
need to submit this kernel driver.
Thanks,
David
next prev parent reply other threads:[~2006-12-02 19:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-01 20:37 David Lopez
2006-12-01 21:18 ` Greg KH
2006-12-02 0:12 ` David Lopez
2006-12-02 7:48 ` Greg KH
2006-12-02 19:51 ` David Lopez [this message]
2006-12-02 12:52 ` Pavel Machek
2006-12-02 18:33 ` David Lopez
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=571a92f0612021151r25849c81md2f44e29532c5c73@mail.gmail.com \
--to=dave.l.lopez@gmail.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
/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
all inboxes | Powered by JetHome®