On 12/2/06, Greg KH <[email protected]> wrote:
On Fri, Dec 01, 2006 at 05:12:56PM -0700, David Lopez wrote:
> On 12/1/06, Greg KH <[email protected]> wrote:
> >On Fri, Dec 01, 2006 at 01:37:22PM -0700, David Lopez wrote:
> >> From: David Lopez <[email protected]>
> >
> >> + /* 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
