On Wed, 26 Feb 2003, Alan Stern wrote:
> As it turns out, this still generates a compiler warning. There's a
> mistake in the min() and max() macros in include/linux/kernel.h. I will
> post something about that on the linux kernel mailing list.
I spoke too soon (don't you just hate it when th
On Tue, 25 Feb 2003, David Brownell wrote:
> Alan Stern wrote:
> > Heck, I've barely had a chance to write it, let alone test it. In fact,
> > it seemed clear that nobody had tried any testing recently. One of the
> > minor bugs I fixed was a subroutine call that passed a structure rather
> > th
On Tue, 25 Feb 2003, David Brownell wrote:
> Did you have a chance to test this ... perhaps using "dummy_hcd"
> and the "gadget zero" driver, which is likely the most accessible
> implementation? Or there's some ez-usb firmware Martin Diehl wrote,
> which ought to work if you have some ez-usb bas
Thanks for following up, I'll take a look.
Did you have a chance to test this ... perhaps using "dummy_hcd"
and the "gadget zero" driver, which is likely the most accessible
implementation? Or there's some ez-usb firmware Martin Diehl wrote,
which ought to work if you have some ez-usb based devic
This patch for usb-skeleton.c, based on earlier work of David Brownell,
fixes a number of errors:
Checking urb->status to see whether the urb had completed was racy
and unsafe.
The read transfer count was calculated wrong.
An unused struct work_struct has been re
On Fri, Feb 21, 2003 at 01:12:47PM -0500, Alan Stern wrote:
> I noticed that usb-skeleton.c still has a TODO entry referring to a race
> involving urb->status, so I took a closer look. Fixing that race will be
> easy, and I will be happy to submit a patch for it. But there are two
> other problem
Alan Stern wrote:
I noticed that usb-skeleton.c still has a TODO entry referring to a race
involving urb->status, so I took a closer look. Fixing that race will be
easy, and I will be happy to submit a patch for it. But there are two
FWIW, here's a patch I started to put together (unfinished). F
I noticed that usb-skeleton.c still has a TODO entry referring to a race
involving urb->status, so I took a closer look. Fixing that race will be
easy, and I will be happy to submit a patch for it. But there are two
other problems, partially related. Is it worthwhile to try to address
them all?
