Am Mittwoch, 9. Mai 2007 00:06 schrieb Alan Stern:
> On Tue, 8 May 2007, Oliver Neukum wrote:
> > Who would send a signal? If this is called with pending URBs, aren't
> > tasks frozen?
>
> disconnect() can be called as a result of a user doing:
>
> echo -n $device_name >/sys/bus/usb/drive
On Tue, 8 May 2007, Oliver Neukum wrote:
> Am Dienstag, 8. Mai 2007 20:33 schrieb Alan Stern:
> > > > > +int usb_wait_anchor_empty_timeout(struct usb_anchor *anchor, int
> > > > > timeout)
> > > > > +{
> > > > > + int res;
> > > > > +
> > > > > + res = wait_event_timeout(anchor->wait,
> > > > >
Am Dienstag, 8. Mai 2007 20:33 schrieb Alan Stern:
> > > > +int usb_wait_anchor_empty_timeout(struct usb_anchor *anchor, int
> > > > timeout)
> > > > +{
> > > > + int res;
> > > > +
> > > > + res = wait_event_timeout(anchor->wait, list_empty(&anchor->urb_list),
> > > > timeout);
> > >
> > > Mayb
On Tue, 8 May 2007, Oliver Neukum wrote:
> Am Montag, 7. Mai 2007 21:23 schrieb Alan Stern:
> > On Mon, 7 May 2007, Oliver Neukum wrote:
>
> > > +int usb_wait_anchor_empty_timeout(struct usb_anchor *anchor, int timeout)
> > > +{
> > > + int res;
> > > +
> > > + res = wait_event_timeout(anchor->wa
Am Montag, 7. Mai 2007 21:23 schrieb Alan Stern:
> On Mon, 7 May 2007, Oliver Neukum wrote:
> > +int usb_wait_anchor_empty_timeout(struct usb_anchor *anchor, int timeout)
> > +{
> > + int res;
> > +
> > + res = wait_event_timeout(anchor->wait, list_empty(&anchor->urb_list),
> > timeout);
>
>
On Mon, 7 May 2007, Oliver Neukum wrote:
> Am Samstag, 5. Mai 2007 17:30 schrieb Alan Stern:
>
> > The bound isn't on the time a device may have data -- it's on the time
> > allowed for a transfer to complete. And the upper bound would be imposed
> > by the driver. How long is it willing to h
Am Samstag, 5. Mai 2007 17:30 schrieb Alan Stern:
> The bound isn't on the time a device may have data -- it's on the time
> allowed for a transfer to complete. And the upper bound would be imposed
> by the driver. How long is it willing to hold up suspend processing
> because of ongoing I/O?
Am Samstag, 5. Mai 2007 17:30 schrieb Alan Stern:
> > What makes you sure it is abnormal? What would impose an upper bound
> > on the time a device may have data?
>
> The bound isn't on the time a device may have data -- it's on the time
> allowed for a transfer to complete. And the upper bound
On Fri, 4 May 2007, Oliver Neukum wrote:
> Am Freitag, 4. Mai 2007 21:46 schrieb Alan Stern:
> > On Fri, 4 May 2007, Oliver Neukum wrote:
> >
> > > > A better approach would be to have a routine which would block until
> > > > all
> > > > URBs on an anchor have completed. With a timeout, so th
Am Freitag, 4. Mai 2007 21:46 schrieb Alan Stern:
> On Fri, 4 May 2007, Oliver Neukum wrote:
>
> > > A better approach would be to have a routine which would block until all
> > > URBs on an anchor have completed. With a timeout, so that they can be
> > > killed if they take too long.
> >
> >
On Fri, 4 May 2007, Oliver Neukum wrote:
> > A better approach would be to have a routine which would block until all
> > URBs on an anchor have completed. With a timeout, so that they can be
> > killed if they take too long.
>
> I can't follow your logic here. The partial completion case has
Am Freitag, 4. Mai 2007 17:35 schrieb Alan Stern:
> On Fri, 4 May 2007, Oliver Neukum wrote:
> This isn't as bad as you think. usbcore makes no guarantees about the
> order of delivery of URBs for differing endpoints. Neither does the USB
> spec.
OK.
> All that matters is the order of URBs
On Friday 04 May 2007, Oliver Neukum wrote:
> Am Freitag, 4. Mai 2007 06:47 schrieb Greg KH:
> >
> > My opinion is that we need to ensure that we can still do the
> > "fire-and-forget" type driver :)
>
> Did you intentionally not mention them needing to be easy to use as
> well as possible?
>
>
On Fri, 4 May 2007, Oliver Neukum wrote:
> Well, forgetting your URBs has the obvious problem that you have no
> legitimate reference to call usb_kill_urb() with. So keeping them in a list
> the driver keeps up to date is not an option. But they have to be on a list.
> The URBs should be killed wh
Am Freitag, 4. Mai 2007 06:47 schrieb Greg KH:
> On Thu, May 03, 2007 at 11:05:54AM -0400, Alan Stern wrote:
> > On Thu, 3 May 2007, Oliver Neukum wrote:
> >
> > > Am Donnerstag, 3. Mai 2007 16:03 schrieb Alan Stern:
> > > > On Thu, 3 May 2007, Oliver Neukum wrote:
> > > >
> > > > > > > How about
Am Freitag, 4. Mai 2007 06:47 schrieb Greg KH:
> On Thu, May 03, 2007 at 11:05:54AM -0400, Alan Stern wrote:
> > On Thu, 3 May 2007, Oliver Neukum wrote:
> >
> > > Am Donnerstag, 3. Mai 2007 16:03 schrieb Alan Stern:
> > > > On Thu, 3 May 2007, Oliver Neukum wrote:
> > > >
> > > > > > > How about
On Thu, May 03, 2007 at 11:05:54AM -0400, Alan Stern wrote:
> On Thu, 3 May 2007, Oliver Neukum wrote:
>
> > Am Donnerstag, 3. Mai 2007 16:03 schrieb Alan Stern:
> > > On Thu, 3 May 2007, Oliver Neukum wrote:
> > >
> > > > > > How about exporting usb_disable_interface() and
> > > > > > usb_enabl
On Thu, 3 May 2007, Oliver Neukum wrote:
> Am Donnerstag, 3. Mai 2007 16:03 schrieb Alan Stern:
> > On Thu, 3 May 2007, Oliver Neukum wrote:
> >
> > > > > How about exporting usb_disable_interface() and
> > > > > usb_enable_interface()?
> > > > > It doesn't solve the problem for endpoint 0, but
Am Donnerstag, 3. Mai 2007 16:03 schrieb Alan Stern:
> On Thu, 3 May 2007, Oliver Neukum wrote:
>
> > > > How about exporting usb_disable_interface() and usb_enable_interface()?
> > > > It doesn't solve the problem for endpoint 0, but this case is rare.
> > >
> > > We could; it would save drivers
On Thu, 3 May 2007, Oliver Neukum wrote:
> > > How about exporting usb_disable_interface() and usb_enable_interface()?
> > > It doesn't solve the problem for endpoint 0, but this case is rare.
> >
> > We could; it would save drivers the trouble of keeping track of their own
> > URBs. Do you hav
Am Mittwoch, 2. Mai 2007 23:14 schrieb Alan Stern:
> On Wed, 2 May 2007, Oliver Neukum wrote:
>
> > Am Mittwoch, 2. Mai 2007 16:15 schrieb Alan Stern:
> > > On Wed, 2 May 2007, Oliver Neukum wrote:
> > >
> > > > Hi,
> > > >
> > > > I was looking at the skeleton driver. It drops any reference to
On Wed, 2 May 2007, Oliver Neukum wrote:
> Am Mittwoch, 2. Mai 2007 16:15 schrieb Alan Stern:
> > On Wed, 2 May 2007, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > I was looking at the skeleton driver. It drops any reference to its
> > > URBs in the write path. This means they cannot be killed
Am Mittwoch, 2. Mai 2007 16:15 schrieb Alan Stern:
> On Wed, 2 May 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > I was looking at the skeleton driver. It drops any reference to its
> > URBs in the write path. This means they cannot be killed in
> > suspend(). Is this an actual requirement. It seem
On Wed, 2 May 2007, Oliver Neukum wrote:
> Hi,
>
> I was looking at the skeleton driver. It drops any reference to its
> URBs in the write path. This means they cannot be killed in
> suspend(). Is this an actual requirement. It seems to me that one
> could let them error out when the system goes
24 matches
Mail list logo
