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
[Linux-usb-users] handling timeouts on usb_bulk_msg
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.
My read function is below.
Many thanks
Andy
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 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
info("usbDIO: Read retval: %d, count: %lu, bytesRead: %d",
retval, count, bytesRead);
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)
{
info("usbDIO: Read timeout");
// If timedout, just return 0 bytes read
retval = 0;
}
}
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
