Hi Greg,
this is syncing 2.4 pegasus driver with recent 2.5
changes. Since it is fixing a few bugs i hope the
patch will be applied in 2.4 tree as well.
I tested it on my system and it seems ok.
Petko
PS: The diff is generated against 2.4.17 but as long as
there is no
Hi,
this patch is quite trivial.
Related question:
This code in usbnet_stop
while (skb_queue_len (&dev->rxq)
&& skb_queue_len (&dev->txq)
&& skb_queue_len (&dev->done)) {
set_current_state (TASK_UNINTERRUPTIBLE);
On Fri, Feb 01, 2002 at 11:36:44AM -0800, David Brownell wrote:
> This is against 2.5.3; it includes two bugfixes::
Looks good, applied.
>
> - doesn't assume CONFIG_DEBUG_SLAB
> - unlink from interrupt completions work
>
> And a fair amount of cleanup (most of the patch, by size):
>
>
On Wed, Jan 30, 2002 at 12:24:13PM -0800, David Brownell wrote:
> "> " == "Patrick Mochel" <[EMAIL PROTECTED]>
>
> > You have a PCI device that is the USB controller. You create a child of
> > that represents the USB bus. Then, devices are added as children of that.
> >
> > Logically, couldn't
On Wed, Jan 30, 2002 at 12:07:26PM -0800, David Brownell wrote:
> > And also remember, the status file in a device's directory also provides
> > a _lot_ of information. We haven't even started to fill up the fields
> > there...
>
> And there can be a lot more such files. Though that 4KB limit
>
On Fri, Feb 01, 2002 at 04:05:15PM -0800, Petko Manolov wrote:
> Hi Greg,
>
> will you please use this pegasus.c.diff instead of the previous
> one... another memory leak was found by Oliver.
> It is funny how such a small driver can leak so much :-)
Looks good, I'll apply this one.
than
On Fri, Feb 01, 2002 at 03:50:44PM -0800, Petko Manolov wrote:
> >it seems that pegasus_probe() has a memory leak in the error case and
> >pegasus_disconnect() fails to unlink urbs before it frees them.
>
>
> These urbs used to be staticly allocated and i don't really know
> why Greg changed the
Hi Greg,
will you please use this pegasus.c.diff instead of the previous
one... another memory leak was found by Oliver.
It is funny how such a small driver can leak so much :-)
Petko
Petko Manolov wrote:
> Hi Greg,
>
> two things this time:
> - suppress str
> it seems that pegasus_probe() has a memory leak in the error case and
> pegasus_disconnect() fails to unlink urbs before it frees them.
These urbs used to be staticly allocated and i don't really know
why Greg changed them to dynamicly allocated not so long ago.
I guess the answer is somewhere
Hi,
it seems that pegasus_probe() has a memory leak in the error case and
pegasus_disconnect() fails to unlink urbs before it frees them.
A patch is included.
Regards
Oliver
--- pegasus.c.alt Sat Feb 2 00:29:17 2002
+++ pegasus.c Sat Feb 2 00:34:32 2002
@@ -885
Hi Greg,
two things this time:
- suppress string concatenate with __FUNCTION__ macro warning
(gcc-3.0.3 and above);
- 2 vendors (Compaq and Hawking) and 3 more devices added;
the patch is against 2.5.3.
Petko
--- linux-2.5.3/drivers/usb/pegasus
This is against 2.5.3; it includes two bugfixes::
- doesn't assume CONFIG_DEBUG_SLAB
- unlink from interrupt completions work
And a fair amount of cleanup (most of the patch, by size):
- doesn't force debugging on
- updated copyright/license statements
- slightly smaller obj
On Thu, Jan 31, 2002 at 05:40:49PM -0800, David Brownell wrote:
> This is a minor cleanup patch. It makes a message just
> show when debugging ... the situation is harmless, so it
> should not normally trigger a warning (as it now does).
Thanks, I've added this to the 2.4 and 2.5 trees.
greg k-
The usb_set_interface() call sets this ... if drivers always
(and only) use that in their probe() routines, and don't issue
SET_INTERFACE calls directly (bypassing that), there's
no problem keeping that in sync with the device state.
On the other hand, the probe() sequence modifies that field
wit
This is a minor cleanup patch. It makes a message just
show when debugging ... the situation is harmless, so it
should not normally trigger a warning (as it now does).
- Dave
usb-0131.patch
Description: Binary data
On Thu, Jan 31, 2002 at 10:30:23PM +0100, Pavel Machek wrote:
> Hi!
>
> > due to the use of sleep_on in vicam.c there is a small window of a race that
> > causes a neverending sleep. Fix is by going for standard waitqueues.
>
> Looks good, Greg please apply.
Added to my 2.4 and 2.5 trees.
tha
Hi,
in hub.c sleep_on is used. Thus there's a window during which an event that
should be processed could be queued instead. The included patch should fix it.
Regards
Oliver
--- hub.c.alt Fri Feb 1 16:41:16 2002
+++ hub.c Fri Feb 1 16:49:17 2002
@@ -878,6 +878,9
On Friday 01 February 2002 14:38, Priya Saminathan wrote:
> I am going thru the linux USB driver code...
>
> And When I went through the code I had the following
> doubts..Though it may be a sort of simple queries it
> matters me a lot..
> (i)How the new devices that attach are detected..
> Is tha
I am going thru the linux USB driver code...
And When I went through the code I had the following
doubts..Though it may be a sort of simple queries it
matters me a lot..
(i)How the new devices that attach are detected..
Is that has some thing related with the
kernel_thread(usb_hub_thread...
(ii)H
On Thursday 31 January 2002 22:30, Pavel Machek wrote:
> Hi!
>
> > due to the use of sleep_on in vicam.c there is a small window of a race
> > that causes a neverending sleep. Fix is by going for standard waitqueues.
>
> Looks good, Greg please apply.
>
> Olivier, do you actually have vicam?
No,
Hi!
> due to the use of sleep_on in vicam.c there is a small window of a race that
> causes a neverending sleep. Fix is by going for standard waitqueues.
Looks good, Greg please apply.
Olivier, do you actually have vicam?
21 matches
Mail list logo
