Re: [Linux-usb-users] handling timeouts on usb_bulk_msg
Greg KH wrote: > On Mon, Nov 05, 2007 at 09:00:10PM +, Andrew Greensted wrote: >> Hi All, >> >> I've written a custom device driver based on the usb-skeleton.c file in >> the kernel source. >> >> I want the driver to act in a similar way to when you read from a serial >> port. ie, when you do this: >> >> cat /dev/ttyS0 > > Why not just use the usb-serial core for this instead of trying to roll > your own code? That is what it is there for :) Greg, I really only used the serial port example as a way of describing the functionality I was after. The actual operation requires something a bit more complex. However, with Roger and Oliver's help it's all working fine now. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
Re: [Linux-usb-users] handling timeouts on usb_bulk_msg
On Mon, Nov 05, 2007 at 09:00:10PM +, Andrew Greensted wrote: > Hi All, > > I've written a custom device driver based on the usb-skeleton.c file in > the kernel source. > > I want the driver to act in a similar way to when you read from a serial > port. ie, when you do this: > > cat /dev/ttyS0 Why not just use the usb-serial core for this instead of trying to roll your own code? That is what it is there for :) thanks, greg k-h - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
Re: [Linux-usb-users] handling timeouts on usb_bulk_msg
Am Dienstag 06 November 2007 schrieb Andy Greensted:
> Alan Stern wrote:
> > There are two possible approaches. The easy way is just to use a very,
> > very long timeout. Alternatively, when a timeout does occur don't
> > return to the user; instead loop back and submit another usb_bulk_msg.
> >
> > Alan Stern
>
> As suggested, I've modified my driver to continually retry a
> usb_bulk_msg if a timeout occurs (ETIMEDOUT is returned). My read
> function now only returns if data has been read, or another error type
> occurs.
>
> The only problem now is that a program reading from my device will not
> respond to a ^C (or kill). I guess it's stuck in the read loop waiting
> for data!
>
> Any suggestions? Do I need to adjust the way the 'locking' is working
>
> Here is the modified code:
>
> static ssize_t usbDIO_read(struct file *file, char __user *buffer,
> size_t count, loff_t *ppos)
> {
> struct usbDIO_deviceData *deviceData;
> int retval = 0;
> int bytesRead;
>
> deviceData = (struct usbDIO_deviceData *)file->private_data;
>
> mutex_lock(&deviceData->ioMutex);
>
> if (!deviceData->interface)
> {
> // disconnect() was called
> retval = -ENODEV;
> goto exit;
> }
>
> do
> {
> // Do a blocking bulk read to get data from the device
> retval = usb_bulk_msg(deviceData->device,
> usb_rcvbulkpipe(deviceData->device,
> deviceData->bulk_in_endpointAddr),
> deviceData->bulk_in_buffer,
> min(deviceData->bulk_in_size, count),
> &bytesRead,
> HZ);// 1 second
> }
> while(retval == -ETIMEDOUT);
while (retval == -ETIMEDOUT && !signal_pending(current));
>
> if (retval == 0)
> {
> // If successful, copy the data to userspace
> if (copy_to_user(buffer, deviceData->bulk_in_buffer,
> count)) retval = -EFAULT;
> else retval = bytesRead;
> }
> else
> {
if (retval == -ETIMEDOUT && signal_pending(current))
retval = bytesRead ? bytesRead : -EINTR;
else
> err("usbDIO: %s - Read failed, error %d", __FUNCTION__, retval);
> }
>
> exit:
> mutex_unlock(&deviceData->ioMutex);
> return retval;
> }
Regards
Oliver
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
Re: [Linux-usb-users] handling timeouts on usb_bulk_msg
On Tue, Nov 06, 2007 at 08:40:41AM +, Andy Greensted wrote: > Alan Stern wrote: > > There are two possible approaches. The easy way is just to use a very, > > very long timeout. Alternatively, when a timeout does occur don't > > return to the user; instead loop back and submit another usb_bulk_msg. Alan, Andy, forgive me missing this part of Alan's message. > As suggested, I've modified my driver to continually retry a > usb_bulk_msg if a timeout occurs (ETIMEDOUT is returned). My read > function now only returns if data has been read, or another error type > occurs. > > The only problem now is that a program reading from my device will not > respond to a ^C (or kill). I guess it's stuck in the read loop waiting > for data! For that you need my suggestion to check for signals. Just grep a bit in the kernel sources and you'll find an example. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
Re: [Linux-usb-users] handling timeouts on usb_bulk_msg
On Mon, Nov 05, 2007 at 04:10:35PM -0500, Alan Stern wrote: > On Mon, 5 Nov 2007, Andrew Greensted wrote: > > > Hi All, > > > > I've written a custom device driver based on the usb-skeleton.c file in > > the kernel source. > > > > I want the driver to act in a similar way to when you read from a serial > > port. ie, when you do this: > > > > cat /dev/ttyS0 > > > > it will wait for data to appear on the port and output to the terminal. > > It doesn't timeout, or close the connection when no data is available. > > In my case the data source is an IN endpoint from a custom usb board. > > > > The problem is how do I stop cat (or any other program) closing the > > connection when the read function timesout (the condition when no data > > is yet available). > > > > I've tried checking to see if the return value from usb_bulk_msg is > > ETIMEDOUT and returning 0 (no bytes read) from my read function rather > > than the error, but cat still exits. If you return "0" on the timeout, standard unix interfaces define this as end-of-file. So cat is correct in interpreting this as EOF and exiting. In your driver, you should NOT return if you get the ETIMEDOUT return, and simply call usb_bulk_msg again. This is entirely acceptable. You will find that doing something about signals is worth the trouble. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
Re: [Linux-usb-users] handling timeouts on usb_bulk_msg
Alan Stern wrote:
> There are two possible approaches. The easy way is just to use a very,
> very long timeout. Alternatively, when a timeout does occur don't
> return to the user; instead loop back and submit another usb_bulk_msg.
>
> Alan Stern
As suggested, I've modified my driver to continually retry a
usb_bulk_msg if a timeout occurs (ETIMEDOUT is returned). My read
function now only returns if data has been read, or another error type
occurs.
The only problem now is that a program reading from my device will not
respond to a ^C (or kill). I guess it's stuck in the read loop waiting
for data!
Any suggestions? Do I need to adjust the way the 'locking' is working
Here is the modified code:
static ssize_t usbDIO_read(struct file *file, char __user *buffer,
size_t count, loff_t *ppos)
{
struct usbDIO_deviceData *deviceData;
int retval = 0;
int bytesRead;
deviceData = (struct usbDIO_deviceData *)file->private_data;
mutex_lock(&deviceData->ioMutex);
if (!deviceData->interface)
{
// disconnect() was called
retval = -ENODEV;
goto exit;
}
do
{
// Do a blocking bulk read to get data from the device
retval = usb_bulk_msg(deviceData->device,
usb_rcvbulkpipe(deviceData->device,
deviceData->bulk_in_endpointAddr),
deviceData->bulk_in_buffer,
min(deviceData->bulk_in_size, count),
&bytesRead,
HZ);// 1 second
}
while(retval == -ETIMEDOUT);
if (retval == 0)
{
// If successful, copy the data to userspace
if (copy_to_user(buffer, deviceData->bulk_in_buffer,
count)) retval = -EFAULT;
else retval = bytesRead;
}
else
{
err("usbDIO: %s - Read failed, error %d", __FUNCTION__, retval);
}
exit:
mutex_unlock(&deviceData->ioMutex);
return retval;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
Re: [Linux-usb-users] handling timeouts on usb_bulk_msg
On Mon, 5 Nov 2007, Andrew Greensted wrote: > Hi All, > > I've written a custom device driver based on the usb-skeleton.c file in > the kernel source. > > I want the driver to act in a similar way to when you read from a serial > port. ie, when you do this: > > cat /dev/ttyS0 > > it will wait for data to appear on the port and output to the terminal. > It doesn't timeout, or close the connection when no data is available. > In my case the data source is an IN endpoint from a custom usb board. > > The problem is how do I stop cat (or any other program) closing the > connection when the read function timesout (the condition when no data > is yet available). > > I've tried checking to see if the return value from usb_bulk_msg is > ETIMEDOUT and returning 0 (no bytes read) from my read function rather > than the error, but cat still exits. > > I've also tried setting the timeout parameter in usb_bulk_msg to 0 (wait > forever). But then you can't exit (^c) or even kill the program reading > from the port. There are two possible approaches. The easy way is just to use a very, very long timeout. Alternatively, when a timeout does occur don't return to the user; instead loop back and submit another usb_bulk_msg. Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
