Am Sonntag, 23. Februar 2003 14:57 schrieb David Brownell:
> Oliver Neukum wrote:
> >>>Under some circumstances, most obviously the disconnect ioctl,
> >>>we need to disconnect only one of the interfaces of a device.
> >>>How are we to do that if we queue by device only?
> >>
> >>Are there or are t
[ re your potential usb-ohci/2.4 patch ]
It won't leak EDs on power management. The cleanup will just be deferred
until power comes back on. Big deal.
Not on the D3cold resume path -- that can't be deferred.
I haven't looked at the PM paths yet, but if the D3cold path is via
normal PCI exit pat
Oliver Neukum wrote:
Under some circumstances, most obviously the disconnect ioctl,
we need to disconnect only one of the interfaces of a device.
How are we to do that if we queue by device only?
Are there or are there not both (a) a set of URBs to check,
and (b) records of the current configuratio
> > Under some circumstances, most obviously the disconnect ioctl,
> > we need to disconnect only one of the interfaces of a device.
> > How are we to do that if we queue by device only?
>
> Are there or are there not both (a) a set of URBs to check,
> and (b) records of the current configuration
On Sat, Feb 22, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> >>>Back to the patch I've attached. It's against 2.4.19-pre3 (I'll update
> >>>to Greg's CVS tree) and hasn't had the level of testing necessary to
> >>>call it good. I also want to recheck that I caught all of the necessary
> >>>pat
Back to the patch I've attached. It's against 2.4.19-pre3 (I'll update
to Greg's CVS tree) and hasn't had the level of testing necessary to
call it good. I also want to recheck that I caught all of the necessary
paths.
Seems like the main change there is that after disconnect, EDs
get cleaned up in
This is fundamentally the problem. Your vision of how stuff is supposed
to work in the USB code is solely your vision and doesn't match what was
intended when I wrote the code or what the majority of the code does.
You can keep thinking whatever you want, but it ain't reality.
ERm, "person 1's cod
Am Samstag, 22. Februar 2003 00:15 schrieben Sie:
> >>A per-device list is sufficient, and a lot cheaper to maintain.
> >>Doing it per-interface would add work to the submit path that's
> >>hardly ever needed ... better to have that work delayed until
> >>it's actually needed.
> >
> > Then how to i
A per-device list is sufficient, and a lot cheaper to maintain.
Doing it per-interface would add work to the submit path that's
hardly ever needed ... better to have that work delayed until
it's actually needed.
Then how to implement usb_reset_device() ?
In some straightforward manner. Rememberi
> > Secondly, if I understand the code correctly, it keeps per device lists.
> > That's not enough. The lists must be per interface, think configuration
> > changes.
>
> A per-device list is sufficient, and a lot cheaper to maintain.
> Doing it per-interface would add work to the submit path that's
On Thu, Feb 20, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>Having looked at the history of that misnamed API:
> >>
> >> - Originally provided in 2.2.10 or so, I think OHCI was the only
> >>user. It was misnamed at that time, given that it was used
> >>only to handshake "device
Having looked at the history of that misnamed API:
- Originally provided in 2.2.10 or so, I think OHCI was the only
user. It was misnamed at that time, given that it was used
only to handshake "device is gone".
- Sometime in the 2.3 series, someone made a change to make the
usage in
Alan Stern wrote:
On Wed, 19 Feb 2003, David Brownell wrote:
That assumes an incorrectly written disconnect() routine. And
the two changes identified (did you notice that SCSI hot-unplug
discussion identified _exactly the same_ two changes??) would
prevent that happening: (a) no more submissi
On Wed, 19 Feb 2003, David Brownell wrote:
> That assumes an incorrectly written disconnect() routine. And
> the two changes identified (did you notice that SCSI hot-unplug
> discussion identified _exactly the same_ two changes??) would
> prevent that happening: (a) no more submissions are possi
Oliver Neukum wrote:
But we don't really _have_ to keep track of all of them, right? And it
Someone needs to, but it doesn't need to be the device driver. The
current approach has "hcd.c" do it, part of usbcore.
A part that doesn't need to be used. It's a little late to break all the
littl
On Thu, 20 Feb 2003, Greg KH wrote:
> On Thu, Feb 20, 2003 at 02:46:51AM +0100, Oliver Neukum wrote:
> > > What? If a driver is undergoing unload, then any kind of return from
> > > usb_submit_urb() (error or not) will cause an oops.
> >
> > Exactly. You are checking for an error that you can't h
On Thu, 20 Feb 2003, Greg KH wrote:
> On Wed, Feb 19, 2003 at 08:28:57PM -0500, Johannes Erdfelt wrote:
> > > You've said that if a device is disconnected, it's urbs will eventually
> > > timeout, right? So everything should be fine, given what I say below...
> >
> > Actually, not in every case.
On Wed, Feb 19, 2003 at 08:28:57PM -0500, Johannes Erdfelt wrote:
> > You've said that if a device is disconnected, it's urbs will eventually
> > timeout, right? So everything should be fine, given what I say below...
>
> Actually, not in every case. If the driver was unloaded because the
> sysad
On Thu, Feb 20, 2003 at 02:46:51AM +0100, Oliver Neukum wrote:
> > What? If a driver is undergoing unload, then any kind of return from
> > usb_submit_urb() (error or not) will cause an oops.
>
> Exactly. You are checking for an error that you can't handle.
> What would usb_submit_urb() do if inc
On Thursday 20 February 2003 02:13, Oliver Neukum wrote:
> Am Donnerstag, 20. Februar 2003 01:47 schrieb Greg KH:
> > On Thu, Feb 20, 2003 at 01:45:09AM +0100, Oliver Neukum wrote:
> > > Besides, what are you to do if incrementing a usage count in
> > > usb_submit_urb() fails ? By definition you ca
> > But we don't really _have_ to keep track of all of them, right? And it
>
> Someone needs to, but it doesn't need to be the device driver. The
> current approach has "hcd.c" do it, part of usbcore.
A part that doesn't need to be used. It's a little late to break all the
little HCDs, isn't i
Oliver Neukum wrote:
For (b) there are several options. Today we expect (b1) device
driver handles all in disconnect(), except that to guard against
bugs there sometimes (b2) HCD may need to get involved. I'd
think a cleaner solution would be (b3) usbcore kills them all;
less work for device dri
Greg KH wrote:
On Wed, Feb 19, 2003 at 05:08:14PM -0800, David Brownell wrote:
But what about drivers that fire off urbs and don't keep a pointer to
them around? They don't know if all of their urbs are completed or not,
nor should they really care. The visor driver is one good example of
this
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > Absolutely right. And IMHO to a device driver that state is reached after
> > > it returns from disconnect().
> >
> > I don't see why that is advantageous.
> >
> > It sounds like it would just complicate the code even more.
>
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 20. Februar 2003 02:25 schrieb Greg KH:
> > On Wed, Feb 19, 2003 at 05:08:14PM -0800, David Brownell wrote:
> > > >But what about drivers that fire off urbs and don't keep a pointer to
> > > >them around? They don't kn
Am Donnerstag, 20. Februar 2003 02:25 schrieb Greg KH:
> On Wed, Feb 19, 2003 at 05:08:14PM -0800, David Brownell wrote:
> > >But what about drivers that fire off urbs and don't keep a pointer to
> > >them around? They don't know if all of their urbs are completed or not,
> > >nor should they real
> > Absolutely right. And IMHO to a device driver that state is reached after
> > it returns from disconnect().
>
> I don't see why that is advantageous.
>
> It sounds like it would just complicate the code even more.
How so, this is the current rule, isn't it?
> > > > > I actually don't have a
Am Donnerstag, 20. Februar 2003 02:11 schrieb Greg KH:
> On Thu, Feb 20, 2003 at 02:13:29AM +0100, Oliver Neukum wrote:
> > Am Donnerstag, 20. Februar 2003 01:47 schrieb Greg KH:
> > > On Thu, Feb 20, 2003 at 01:45:09AM +0100, Oliver Neukum wrote:
> > > > Besides, what are you to do if incrementing
On Wed, Feb 19, 2003 at 05:08:14PM -0800, David Brownell wrote:
>
> >But what about drivers that fire off urbs and don't keep a pointer to
> >them around? They don't know if all of their urbs are completed or not,
> >nor should they really care. The visor driver is one good example of
> >this.
>
> For (b) there are several options. Today we expect (b1) device
> driver handles all in disconnect(), except that to guard against
> bugs there sometimes (b2) HCD may need to get involved. I'd
> think a cleaner solution would be (b3) usbcore kills them all;
> less work for device drivers too.
On Thu, Feb 20, 2003 at 02:25:48AM +0100, Oliver Neukum wrote:
>
> What do you do on disconnect() ? How do you make sure that a
> completion handler will eventually be called if nobody's there to unlink
> it.
Nothing different in disconnect(). Remember that's different from
module_exit(), and mo
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 07:57:29PM -0500, Johannes Erdfelt wrote:
> > >
> > > Heh. No, urbs are referenced counted now. So a driver can do the
> > > following just fine:
> > > - usb_alloc_urb()
> > > - urb data = kmalloc()
> > > -
Am Donnerstag, 20. Februar 2003 01:45 schrieb Greg KH:
> On Wed, Feb 19, 2003 at 07:33:57PM -0500, Johannes Erdfelt wrote:
> > > But what about drivers that fire off urbs and don't keep a pointer to
> > > them around? They don't know if all of their urbs are completed or
> > > not, nor should they
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > > Actually, it seems to me that that unlinking after disconnect would
> > > > need to be a requirement for random disconnects to work.
> > >
> > > After physical disconnect, or logical disconnect?
> >
> > Physical. I consider l
On Thu, Feb 20, 2003 at 02:13:29AM +0100, Oliver Neukum wrote:
> Am Donnerstag, 20. Februar 2003 01:47 schrieb Greg KH:
> > On Thu, Feb 20, 2003 at 01:45:09AM +0100, Oliver Neukum wrote:
> > > Besides, what are you to do if incrementing a usage count in
> > > usb_submit_urb() fails ? By definition
On Thu, Feb 20, 2003 at 02:08:44AM +0100, Oliver Neukum wrote:
> To beat that we'd need an awful amount of refcounting and locking.
No, a simple module reference count here will fix everything just fine.
thanks,
greg k-h
---
This SF.net email
Am Donnerstag, 20. Februar 2003 01:47 schrieb Greg KH:
> On Thu, Feb 20, 2003 at 01:45:09AM +0100, Oliver Neukum wrote:
> > Besides, what are you to do if incrementing a usage count in
> > usb_submit_urb() fails ? By definition you cannot return to the driver.
>
> Huh? usb_submit_urb() can fail to
On Wed, Feb 19, 2003 at 08:05:17PM -0500, Johannes Erdfelt wrote:
>
> Yes, so it does need to keep track of them, but only a count I guess.
Ah, how about the module reference count then, it's extreemly
lightweight and SMP safe :)
That way every driver that wants to do this doesn't have to, as th
On Wed, Feb 19, 2003 at 04:56:28PM -0800, David Brownell wrote:
> Greg KH wrote:
> >On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
> >
> >>Greg KH wrote:
> >>
> >>>Hm, maybe we should mark the device gone at the beginning of this call,
> >>>or right at the time we realize it's gone
> > > Actually, it seems to me that that unlinking after disconnect would
> > > need to be a requirement for random disconnects to work.
> >
> > After physical disconnect, or logical disconnect?
>
> Physical. I consider logical disconnect when the last reference to the
> device structure is put (i
On Wed, Feb 19, 2003 at 07:54:13PM -0500, Johannes Erdfelt wrote:
> On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> >
> > > Does the existing serial driver submit URBs after the device is
> > > physically removed? (Like if an application still has an fd open when
> > > the device
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 07:57:29PM -0500, Johannes Erdfelt wrote:
> > >
> > > Heh. No, urbs are referenced counted now. So a driver can do the
> > > following just fine:
> > > - usb_alloc_urb()
> > > - urb data = kmalloc()
> > > -
On Wed, Feb 19, 2003 at 07:57:29PM -0500, Johannes Erdfelt wrote:
> >
> > Heh. No, urbs are referenced counted now. So a driver can do the
> > following just fine:
> > - usb_alloc_urb()
> > - urb data = kmalloc()
> > - usb_submit_urb()
> > - usb_free_urb()
> >
> > Then later in
But what about drivers that fire off urbs and don't keep a pointer to
them around? They don't know if all of their urbs are completed or not,
nor should they really care. The visor driver is one good example of
this.
It would certainly simplify things if that (b) change I mentioned
were to ta
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 07:33:57PM -0500, Johannes Erdfelt wrote:
> > > But what about drivers that fire off urbs and don't keep a pointer to
> > > them around? They don't know if all of their urbs are completed or not,
> > > nor should th
On Thu, Feb 20, 2003 at 01:45:09AM +0100, Oliver Neukum wrote:
>
> Besides, what are you to do if incrementing a usage count in
> usb_submit_urb() fails ? By definition you cannot return to the driver.
Huh? usb_submit_urb() can fail today any number of different ways.
-ENODEV would work just fin
On Wed, Feb 19, 2003 at 07:33:57PM -0500, Johannes Erdfelt wrote:
> > But what about drivers that fire off urbs and don't keep a pointer to
> > them around? They don't know if all of their urbs are completed or not,
> > nor should they really care. The visor driver is one good example of
> > this
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > Does the existing serial driver submit URBs after the device is
> > physically removed? (Like if an application still has an fd open when
> > the device was removed)
>
> Of course it does. _Any_ driver will do so. The window bet
Greg KH wrote:
On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
Greg KH wrote:
Hm, maybe we should mark the device gone at the beginning of this call,
or right at the time we realize it's gone in the hub driver. That would
keep drivers from submitting urbs from within their dis
On Wed, Feb 19, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> but the hcd drivers should have already canceled them, right? Hm, but
> >>>
> >>>Nope, the only way an hcd can know the device is gone is by
> >>>calling the misnamed bus->op->deallocate() routine. And
> >>>because of the me
> Does the existing serial driver submit URBs after the device is
> physically removed? (Like if an application still has an fd open when
> the device was removed)
Of course it does. _Any_ driver will do so. The window between
physical and logical disconnection is unavoidable, if only because
of
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > No, some of the hcds die a horrible death if you try to call unlink on a
> > > urb after the device is gone :(
> >
> > They shouldn't. It should be perfectly valid to do that.
> >
> > Actually, it seems to me that that unlinkin
but the hcd drivers should have already canceled them, right? Hm, but
Nope, the only way an hcd can know the device is gone is by
calling the misnamed bus->op->deallocate() routine. And
because of the mess stemming from that misnaming, that code
path doesn't even try to do that any more.
Hu
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > Does the existing serial driver submit URBs after the device is
> > physically removed? (Like if an application still has an fd open when
> > the device was removed)
>
> Yes, some drivers do this, (the keyspan driver is one, and I think
> > No, some of the hcds die a horrible death if you try to call unlink on a
> > urb after the device is gone :(
>
> They shouldn't. It should be perfectly valid to do that.
>
> Actually, it seems to me that that unlinking after disconnect would need
> to be a requirement for random disconnects to
On Wed, Feb 19, 2003 at 07:12:58PM -0500, Johannes Erdfelt wrote:
> > Hm, uhci-hcd oopses if this happens :)
> > I could reproduce this very easily without that urb change but with the
> > usb-serial changes.
>
> Ahh, and that brings us back to the original patch.
>
> If so, it could be a bug in
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 05:44:54PM -0500, Johannes Erdfelt wrote:
> > On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
> > > > Only because you put that check in
On Wed, Feb 19, 2003 at 05:44:54PM -0500, Johannes Erdfelt wrote:
> On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
> > > Greg KH wrote:
> > > >
> > > >Hm, maybe we should mark the device gone at the beginning of this call
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
> > Greg KH wrote:
> > >
> > >Hm, maybe we should mark the device gone at the beginning of this call,
> > >or right at the time we realize it's gone in the hub driver. That wo
On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
> Greg KH wrote:
> >
> >Hm, maybe we should mark the device gone at the beginning of this call,
> >or right at the time we realize it's gone in the hub driver. That would
> >keep drivers from submitting urbs from within their disconne
Greg KH wrote:
Hm, maybe we should mark the device gone at the beginning of this call,
or right at the time we realize it's gone in the hub driver. That would
keep drivers from submitting urbs from within their disconnect
functions. But it would also prevent them from canceling them... Ah,
O
On Wed, Feb 19, 2003 at 09:29:37AM +0100, Duncan Sands wrote:
> > @@ -853,6 +854,10 @@
> > usbfs_remove_device(dev);
> > }
> > device_unregister(&dev->dev);
> > +
> > + /* mark the device as not present so any further urb submissions for
> > +* this device will fail. */
>
> @@ -853,6 +854,10 @@
> usbfs_remove_device(dev);
> }
> device_unregister(&dev->dev);
> +
> + /* mark the device as not present so any further urb submissions for
> + * this device will fail. */
> + dev->present = 0;
>
> /* Decrement the reference count
ChangeSet 1.1043.1.7, 2003/02/16 09:39:17-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: on-the-fly AAL5/ATM encoding for speedtouch
Add a new encoding routine, udsl_write_cell, which extracts one ATM cell from a skb
and writes it, doing the AAL5/ATM encoding on the fly. To make this possible,
ChangeSet 1.1043.1.23, 2003/02/18 09:29:42-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: speedtouch cleanups
Grab bag of minor cleanups.
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Tue Feb 18 16:37:25 2003
+++ b/drivers/us
ChangeSet 1.1043.1.10, 2003/02/16 09:41:02-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: Missing speedtouch bits
Let's not forget to update the ATM transmission statistics! And
let's not pretend to support AAL0 when we don't.
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/spee
ChangeSet 1.925.62.4, 2003/02/07 16:45:32+11:00, [EMAIL PROTECTED]
[PATCH] USB: cdc-acm memory leak
The Stanford Checker discovered a memory leak in cdc-acm.
This patch to 2.5.59 fixes it. Please apply.
diff -Nru a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
--- a/drivers/usb/cla
ChangeSet 1.1043.1.24, 2003/02/18 15:52:11-08:00, [EMAIL PROTECTED]
[PATCH] USB: add "present" flag to usb_device structure.
This solves lots of races when drivers hold a reference to the usb_device
after the device is physically removed from the system (like when a user
has a open handle.) This
ChangeSet 1.925.62.6, 2003/02/07 17:21:17+11:00, [EMAIL PROTECTED]
[PATCH] Re: Griffin Powermate: Aluminum
> Greg KH says "please send 2.5 patch".
diff -Nru a/drivers/usb/input/Kconfig b/drivers/usb/input/Kconfig
--- a/drivers/usb/input/Kconfig Tue Feb 18 16:45:20 2003
+++ b/drivers/usb/input/K
ChangeSet 1.1043.1.13, 2003/02/17 10:09:44-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: Update CREDITS and MAINTAINERS
diff -Nru a/CREDITS b/CREDITS
--- a/CREDITS Tue Feb 18 16:40:19 2003
+++ b/CREDITS Tue Feb 18 16:40:19 2003
@@ -2746,6 +2746,14 @@
E: [EMAIL PROTECTED]
D: portions of
ChangeSet 1.1043.1.21, 2003/02/18 08:43:30-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: replace speedtouch crc routines
Use the kernel CRC routines rather than a do-it-yourself version.
By the way, I created a common USB Makefile.lib, rather than having
one for the class drivers, and one for
ChangeSet 1.1043.1.3, 2003/02/16 09:37:49-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: yet another trivial speedtouch change
Measure the receive buffer size in ATM cells (53 bytes).
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c
ChangeSet 1.925.62.3, 2003/02/07 16:42:38+11:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: Fix atmsar memory leak
Leak found by the Stanford Checker (patch by Randy Dunlap).
diff -Nru a/drivers/usb/misc/atmsar.c b/drivers/usb/misc/atmsar.c
--- a/drivers/usb/misc/atmsar.c Tue Feb 18 16:46:03 200
ChangeSet 1.1043.1.6, 2003/02/16 09:38:54-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: More infrastructure for new speedtouch send path
Add a new structure, udsl_control. It will live in the sk_buff cb field,
so check there is room for it and bail out during module init if not.
diff -Nru a
ChangeSet 1.1043.1.26, 2003/02/18 16:05:07-08:00, [EMAIL PROTECTED]
[PATCH] USB: serial core fix to solve ordering issues when destroying our objects.
diff -Nru a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
--- a/drivers/usb/serial/usb-serial.c Tue Feb 18 16:36:35 2003
++
ChangeSet 1.925.62.8, 2003/02/07 17:22:22+11:00, [EMAIL PROTECTED]
[PATCH] USB: added device id for kaweth
- additional device id
diff -Nru a/drivers/usb/net/kaweth.c b/drivers/usb/net/kaweth.c
--- a/drivers/usb/net/kaweth.c Tue Feb 18 16:44:47 2003
+++ b/drivers/usb/net/kaweth.c Tue Feb 18
ChangeSet 1.925.62.5, 2003/02/07 16:54:22+11:00, [EMAIL PROTECTED]
[PATCH] USB: pegasus update (2.5)
These are very small and similar csets against both usb-2.4 and usb-2.5
trees. One part of them is adding a missing flag to one of the device
descriptors. The other part is fixing a vendor name
ChangeSet 1.1043.1.4, 2003/02/16 09:38:10-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: infrastructure for new speedtouch send path
Put in infrastructure for the new send code. The only code changes are in the
udsl_usb_probe and udsl_usb_disconnect functions, changed to initialize/finalize th
ChangeSet 1.1107, 2003/02/18 16:33:05-08:00, [EMAIL PROTECTED]
USB: usbnet driver also needs the crc32 code.
Thanks to David Brownell for this.
diff -Nru a/drivers/usb/Makefile.lib b/drivers/usb/Makefile.lib
--- a/drivers/usb/Makefile.lib Tue Feb 18 16:35:37 2003
+++ b/drivers/usb/Makefile.lib
ChangeSet 1.1043.1.15, 2003/02/17 10:13:56-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: speedtouch 330 support
Differences: speedtouch 330 vs the older speedtouch USB:
Vendor and ProdID: no difference (!)
Rev: 2.00 vs 0.00
SerialNumber: 0090D0xx, xx larger for 330
Interface 1, Alt 2:
ChangeSet 1.925.62.7, 2003/02/07 17:21:51+11:00, [EMAIL PROTECTED]
[PATCH] usb_get_driver_np() gives wrong driver name (usb_mouse)
On Thu, Feb 06, 2003, Johannes Erdfelt <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 06, 2003, Boris Duerner <[EMAIL PROTECTED]> wrote:
> > I use the usb_get_driver_np() f
ChangeSet 1.1043.1.20, 2003/02/17 10:41:09-08:00, [EMAIL PROTECTED]
[PATCH] USB: ov511 bugfixes/cleanup
This patch updates the 2.5 ov511 driver to version 1.64. This fixes some
longstanding bugs and cleans the code up a bit.
Changes:
- Eliminate remaining uses of sleep_on()
- Remove unnecessar
ChangeSet 1.925.62.2, 2003/02/07 16:39:47+11:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: trivial speedtouch changes
Get rid of some unused #defines.
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Tue Feb 18 16:46:17 2003
+++ b
ChangeSet 1.1043.1.5, 2003/02/16 09:38:32-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: expose crc defs to speedtouch
Expose some CRC definitions in atmsar.h (for use by speedtouch.c).
diff -Nru a/drivers/usb/misc/atmsar.c b/drivers/usb/misc/atmsar.c
--- a/drivers/usb/misc/atmsar.c Tue Feb 1
ChangeSet 1.1043.1.11, 2003/02/17 10:09:00-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: fix speedtouch micro race
The disconnect routine counts the completed_receivers/spare_senders list
to see if the completion handler has finished. It then kills the tasklet.
However the tasklet was being s
ChangeSet 1.1043.1.9, 2003/02/16 09:40:01-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: speedtouch dead code elimination
Eliminate a pile of code that isn't used anymore now the new send code
is in place, and make some cosmetic changes.
diff -Nru a/drivers/usb/misc/atmsar.c b/drivers/usb/mis
ChangeSet 1.1043.1.12, 2003/02/17 10:09:22-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: Fix speedtouch maxi race
Instead of trying to close all ATM connections in the USB disconnect routine,
just notify the ATM layer that the ATM device should go down when the last
connection is closed. This
ChangeSet 1.1043.1.16, 2003/02/17 10:14:43-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: minor speedtouch changes
Add some comments and debug info.
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Tue Feb 18 16:39:28 2003
+++ b
ChangeSet 1.1043.1.8, 2003/02/16 09:39:39-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: new speedtouch send path
Finally, here is the new code for sending packets. The ATM layer passes us a skb
containing the packet to be sent. We need to encode that as AAL5, and then encapsulate
the result
ChangeSet 1.1106, 2003/02/18 16:27:45-08:00, [EMAIL PROTECTED]
[PATCH] USB: added sched.h to usb.h
Thanks to Matt Wilcox for the info.
diff -Nru a/include/linux/usb.h b/include/linux/usb.h
--- a/include/linux/usb.h Tue Feb 18 16:35:55 2003
+++ b/include/linux/usb.h Tue Feb 18 16:35:
ChangeSet 1.1043.1.22, 2003/02/18 09:22:09-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: speedtouch stability fix fix
It's usually considered stupid to stuff-up like this. However,
for this once we'll just call it "inspired".
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speed
ChangeSet 1.1043.1.25, 2003/02/18 16:03:32-08:00, [EMAIL PROTECTED]
[PATCH] USB serial: fix locking logic
This gets rid of the port semaphore, and the serialization caused by
that, and replaces it with the proper reference counting logic for
the usb serial object.
diff -Nru a/drivers/usb/serial
ChangeSet 1.1043.1.19, 2003/02/17 10:40:43-08:00, [EMAIL PROTECTED]
[PATCH] USB: USB keyboard works after reboot (ehci-hcd)
This resolves a problem caused by "reboot" not actually
doing a clean shutdown of drivers. It uses a reboot
notifier to make sure that typical BIOS code (using the
USB 1.1
ChangeSet 1.925.62.9, 2003/02/07 17:22:54+11:00, [EMAIL PROTECTED]
[PATCH] USB: kaweth fix
this is the length calculation fix against 2.5.
- fix DHCP problem with correct length calculation
Thanks to Oliver Kurth
diff -Nru a/drivers/usb/net/kaweth.c b/drivers/usb/net/kaweth.c
--- a/drivers/
ChangeSet 1.1043.1.14, 2003/02/17 10:10:04-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: add help text for speedtouch
diff -Nru a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
--- a/drivers/usb/misc/Kconfig Tue Feb 18 16:40:03 2003
+++ b/drivers/usb/misc/Kconfig Tue Feb 18 16:40:03 20
ChangeSet 1.1043.1.18, 2003/02/17 10:40:17-08:00, [EMAIL PROTECTED]
[PATCH] USB: sg_complete() warning downgrade
An error check would wrongly fire after usb_sg_cancel().
This patch prevents the misfire, and also makes the
diagnostic (a) more useful, (b) less scarey.
diff -Nru a/drivers/usb/core
ChangeSet 1.1043.1.2, 2003/02/16 09:37:27-08:00, [EMAIL PROTECTED]
[PATCH] USB speedtouch: Even more trivial speedtouch change
Rename UDSL_RECEIVE_BUFFER_SIZE to UDSL_RCV_BUFFER_SIZE.
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c
ChangeSet 1.1043.1.17, 2003/02/17 10:39:56-08:00, [EMAIL PROTECTED]
[PATCH] USB: trivial help texts for drivers/usb/serial/Kconfig
Here are some trivial help texts for drivers/usb/serial/Kconfig.
diff -Nru a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
--- a/drivers/usb/serial/Kconfi
98 matches
Mail list logo
