On Sun, Nov 29, 2015 at 01:28:49PM +0100, Dave Penkler wrote:
> Background:
> When performing a read on an instrument that is executing a function
> that runs longer than the USB timeout the instrument may hang and
> require a device reset to recover. The READ_STATUS_BYTE operation
> always returns even when the instrument is busy permitting to poll
> for the appropriate condition. This capability is referred to in
> instrument application notes on synchronizing acquisitions for other
> platforms.
>
> Signed-off-by: Dave Penkler <dpenkler@xxxxxxxxx>
> ---
> drivers/usb/class/usbtmc.c | 200 +++++++++++++++++++++++++++++++++++++++++++
> include/uapi/linux/usb/tmc.h | 2 +
> 2 files changed, 202 insertions(+)
>
> diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> index 7a11a82..89456df9 100644
> --- a/drivers/usb/class/usbtmc.c
> +++ b/drivers/usb/class/usbtmc.c
> @@ -87,6 +87,19 @@ struct usbtmc_device_data {
> u8 bTag_last_write; /* needed for abort */
> u8 bTag_last_read; /* needed for abort */
>
> + /* data for interrupt in endpoint handling */
> + u8 bNotify1;
> + u8 bNotify2;
> + u16 ifnum;
> + u8 iin_bTag;
> + u8 *iin_buffer;
> + atomic_t iin_data_valid;
> + unsigned int iin_ep;
> + int iin_ep_present;
> + int iin_interval;
> + struct urb *iin_urb;
> + u16 iin_wMaxPacketSize;
> +
> u8 rigol_quirk;
>
> /* attributes from the USB TMC spec for this device */
> @@ -99,6 +112,7 @@ struct usbtmc_device_data {
> struct usbtmc_dev_capabilities capabilities;
> struct kref kref;
> struct mutex io_mutex; /* only one i/o function running at a time */
> + wait_queue_head_t waitq;
> };
> #define to_usbtmc_data(d) container_of(d, struct usbtmc_device_data, kref)
>
> @@ -373,6 +387,83 @@ exit:
> return rv;
> }
>
> +static int usbtmc488_ioctl_read_stb(struct usbtmc_device_data *data,
> + unsigned long arg)
Minor nit, make arg be a "void __user *" here, then there is no need to
cast it later on.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
