All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefani Seibold <stefani@seibold.net>
To: Oliver Neukum <oneukum@suse.de>
Cc: linux-kernel@vger.kernel.org, greg@kroah.com,
	gregkh@linuxfoundation.org,
	thomas.braunstorfinger@rohde-schwarz.com
Subject: Re: [PATCH] add new NRP power meter USB device driver
Date: Thu, 31 May 2012 11:21:40 +0200	[thread overview]
Message-ID: <1338456100.6454.82.camel@wall-e> (raw)
In-Reply-To: <201205311020.50076.oneukum@suse.de>

On Thu, 2012-05-31 at 10:20 +0200, Oliver Neukum wrote:

> > > 
> > > > +		if (arg) {
> > > > +			ret = wait_event_interruptible_timeout(
> > > > +				dev->out_running.wait,
> > > > +				list_empty(&dev->out_running.urb_list),
> > > > +				msecs_to_jiffies(arg));
> > > > +			if (!ret)
> > > > +				return -ETIMEDOUT;
> > > > +			if (ret < 0)
> > > > +				return ret;
> > > > +			return 0;
> > > > +		} else {
> > > > +			return wait_event_interruptible(
> > > > +				dev->out_running.wait,
> > > > +				list_empty(&dev->out_running.urb_list));
> > > > +		}
> > > > +		break;
> > > 
> > > This is very ugly. If you need fsync(), then implement it.
> > > 
> > 
> > fsync() did not meat the requirements, since i need in some case a
> > timeout for the device. poll() will also not help, since it signals only
> > that there is space to write.
> 
> Well, then implement fsync() with interruptible sleep and use a timer
> in user space.
> 

But this will not solve the problem of older software which is still
depending on this ioctl.


> Yes, but this seems to be buggy:
> 
> +	ret = usb_submit_urb(urb, GFP_KERNEL);
> +	if (ret) {
> +		usb_unanchor_urb(urb);
> +		urb_list_add_tail(&dev->read_lock, urb, &dev->in_avail);
> +		nrpz_err("Failed submitting read urb (error %d)", ret);
> +	}
> 
> You have already transfered the data to user space. It seems to me that you
> need to zero out the URB and need to handle the case of getting an URB
> without data.
> 

Okay, i understand what you mean. Zeroing out is not necessary since
usb_submit_urb will set urb->status to -EINPROGRESS. This behavior is
well documented.

I checked it again, and it will work perfectly in case of an error.

And in my opinion it is safe to reuse an urb without reinitialization,
this is a common practice in the callback handlers, so i see no reason
why this should not work in the read() function.

> > > > +static int nrpz_pre_reset(struct usb_interface *intf)
> > > > +{
> > > > +	struct usb_nrpz *dev = usb_get_intfdata(intf);
> > > > +
> > > > +	if (dev)
> > > > +		nrpz_draw_down(dev);
> > > > +	return 0;
> > > > +}
> > > > +
> > > > +static int nrpz_post_reset(struct usb_interface *intf)
> > > > +{
> > > > +	return 0;
> > > > +}
> > > 
> > > And you don't tell user space that the device has been reset?
> > > And what restarts reading?
> > > 
> > 
> > I have no idea how to do this. But i will have a look in the kernel
> > source and figure it out.
> 
> There probably is no generic answer. But I presume a reset will
> reinit the device and destroy anything you set up before, so I guess
> the next read() or write() after a reset has to return an error code that
> tells user space that it has to redo its setup.
> 

Is it okay to kick out the whole ..._reset() thing, since i have no idea
what it is good for.

Greetings,
Stefani



  reply	other threads:[~2012-05-31  9:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-29 19:14 [PATCH] add new NRP power meter USB device driver stefani
2012-05-29 23:15 ` Greg KH
2012-05-31  8:47   ` Stefani Seibold
2012-05-31  9:41     ` Greg KH
2012-06-02  7:10       ` Stefani Seibold
2012-06-02 12:10         ` Greg KH
2012-06-02 15:43           ` Stefani Seibold
2012-05-31  9:53     ` Greg KH
2012-05-31 10:17       ` Oliver Neukum
2012-05-31 12:04         ` Greg KH
2012-05-31 12:32           ` Oliver Neukum
2012-05-31 12:48             ` Greg KH
2012-05-31 14:22               ` Oliver Neukum
2012-05-31 14:32                 ` Greg KH
2012-06-01 13:38                   ` Oliver Neukum
2012-05-30  8:10 ` Oliver Neukum
2012-05-31  7:43   ` Stefani Seibold
2012-05-31  8:20     ` Oliver Neukum
2012-05-31  9:21       ` Stefani Seibold [this message]
2012-06-01 14:16         ` Oliver Neukum
2012-06-01 14:34           ` Alan Cox
2012-06-02  5:57           ` Stefani Seibold
  -- strict thread matches above, loose matches on Subject: below --
2012-06-02 16:18 stefani
2012-06-02 20:24 ` Oliver Neukum
2012-06-03  5:15   ` Stefani Seibold
2012-06-03  8:46 stefani
2012-06-03 11:48 ` Joe Perches
2012-06-13  0:58 ` Greg KH

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=1338456100.6454.82.camel@wall-e \
    --to=stefani@seibold.net \
    --cc=greg@kroah.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oneukum@suse.de \
    --cc=thomas.braunstorfinger@rohde-schwarz.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.