> Ick, no, I will not take this patch, sorry. That's just too much data
> on the stack. Try using skb_clone() or friends if you need a temp copy
> of the skb.
Hi Greg, I guess I didn't make it clear that this was a temporary measure
until I rewrite atmsar_decode_rawcell. I will rewrite atmsar_d
Acording to www.kernel.org bugzilla is only for kernel 2.5.x
So I guess there's not much hope for me. :-(
Jon Smirl wrote:
Try putting it into the kernel bug tracker:
http://bugzilla.kernel.org/
Then post a reference to it on the USB list.
=
Jon Smirl
[EMAIL PROTECTED]
I have a bug in the usb-ohci driver.
Where should I submit this bug report?
Since it looks like nobody in this newsgroup cares.
-Heinrich
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 S
Koen Van Renterghem wrote:
> Hello,
>
> I queue a large numbers of URB's and keep them on a list. Then I wait
> for them to finish or to expire on a timeout.
> You can consider this a bit as the gather/scatterlist functions but with
> a timout.
> Including the timout can, as far as I understand it,
Oliver Neukum wrote:
>
>>Returning a failure code will at least let the driver know that
>>there's a bug in _its_ domain. (Same thing for -ENODEV.) The
>
>
> Well, what would a driver do with knowledge that itself is buggy?
> There's not much you can do in that case.
See my previous response. W
block = kmalloc(EXT_FW_BLOCK_SIZE, GFP_KERNEL|GFP_DMA);
if(block == NULL) return -ENOMEM;
Wrong. Use GFP_KERNEL only.
Alright. I just wanted to be sure it's DMA.
And why is that? Remember that not all HCDs do DMA,
and even those that do aren't usually going to need
to use the "DMA zone".
On Thu, Jan 23, 2003 at 09:06:00AM -0800, David Brownell wrote:
> The support for non-dma HCDs is likely the most interesting bit here.
>
>- makes dma calls behave sensibly when used with host controllers
> that don't use dma (including sl811). usb_buffer_map() is a nop
> while scat
On Thu, Jan 23, 2003 at 10:12:24AM +0100, Duncan Sands wrote:
> speedtouch: move all processing of receive urbs to udsl_atm_processqueue. This has
> several advantages, as will be seen in the next few patches. The most important is
> that it makes it easy to reuse of the urb's buffer (right
On Fri, Jan 24, 2003 at 03:14:06PM +0100, Duncan Sands wrote:
> speedtouch: wait for receive urb completion handlers to finish after calling
> usb_unlink_urb.
Again, doesn't apply.
Sorry,
greg k-h
---
This SF.NET email is sponsored by:
So
On Fri, Jan 24, 2003 at 05:12:25PM +0100, Duncan Sands wrote:
> speedtouch: a pile of cosmetic changes to make me feel happier (no code changes).
Again, didn't apply.
sorry,
greg k-h
---
This SF.NET email is sponsored by:
SourceForge Enterp
On Fri, Jan 24, 2003 at 01:53:06PM +0100, Duncan Sands wrote:
> speedtouch: more robust handling of receive urb failure: retry failed urbs whenever
> a new connection is opened. This should work well with pppd's persist option.
Doesn't apply due to the patch I didn't want to apply.
Sorry,
g
On Thu, Jan 23, 2003 at 09:41:17PM +0100, Duncan Sands wrote:
> speedtouch: recycle the receive urb's buffer. Currently, every time a receive urb
> completes, its old buffer is thrown away and replaced with a new one. This patch
> performs the minor changes needed to reuse the old buffer.
On Tue, 28 Jan 2003, David Brownell wrote:
> Alan Stern wrote:
> >
> > Calls to usb_unlink_urb() while the completion handler is running
> > won't do anything until the handler has returned.
>
> It still violates the API spec: there's no completion callback with
> an unlink status (-ECO
On Tue, Jan 28, 2003 at 08:19:25PM +0100, Oliver Neukum wrote:
> Am Dienstag, 28. Januar 2003 13:54 schrieb Oliver Kurth:
> > Hello!
> >
> > I wrote a new driver for Atmel at76c503 based USB wlan adapters. See
> > the link below in my .signature.
> > Maybe someone wants to look over it. It is stil
> > subsytem may need to continue in a degraded state). However
> > usb_unlink_urb can return:
> > -EINVAL: for usb_retire_urb this means success (not in USB subsystem);
>
> Then what would you return to a driver that passed something like
> a null or otherwise garbage pointer, instead of the cor
Am Dienstag, 28. Januar 2003 13:54 schrieb Oliver Kurth:
> Hello!
>
> I wrote a new driver for Atmel at76c503 based USB wlan adapters. See
> the link below in my .signature.
What's wrong with the existing driver?
> Maybe someone wants to look over it. It is still in development,
> and supports on
Alan Stern wrote:
The whole idea of this exercise is to simplify
things for device drivers by giving them an easy way to unload cleanly.
Drivers don't need API changes for that. They just need to guarantee
they've implemented disconnect() correctly. Unloading is part of
a different kernel s
Alan Stern wrote:
Just for kicks I created a patch (included below) that allocates those
bits from urb->transfer_flags. That's not such a great place, because
it's liable to be overwritten by device drivers. But the only alternative
is to add a whole extra field (like internal_state).
As soon
Duncan Sands wrote:
Hi Dave, my main gripe was that usb_unlink_urb seems quite fragile.
I can't see that at all.
Thinking more about it, what I really want is a function that cancels
usb_submit_urb (lets call it usb_retire_urb): that reliably removes an
urb from the USB subsystem. I thought
Alan Stern wrote:
Calls to usb_unlink_urb() while the completion handler is running
won't do anything until the handler has returned.
It still violates the API spec: there's no completion callback with
an unlink status (-ECONNRESET, -ENOENT). It shouldn't masquerade as
a call that behaved c
Hello,
I queue a large numbers of URB's and keep them on a list. Then I wait for
them to finish or to expire on a timeout.
You can consider this a bit as the gather/scatterlist functions but with a
timout.
Including the timout can, as far as I understand it, lead to race conditions.
If a timeou
Am Montag, 27. Januar 2003 16:41 schrieb Alan Stern:
> Oliver:
>
> In case my message from last Friday fell through the cracks, I'm resending
> it. This patch should do what you want:
Sorry, too much work to do. It's seems alright to me.
Regards
Oliver
Hello!
I wrote a new driver for Atmel at76c503 based USB wlan adapters. See
the link below in my .signature.
Maybe someone wants to look over it. It is still in development,
and supports only ad-hoc mode at the moment. There is one 'exotic'
thing about it: it uses another module which I wrote to
Sorry for asking this but I do not have a device as yet to verify this.
I know that you can for send bulk urbs make the buffer bigger than
wMaxPacketSize.
Can you also do this for Receiving bulk urbs? and will it then use the
larger buffer?
Or should I make receive bulk urbs buffer size = wMaxP
> No, you don't actually know if you're in (2a) about to die horribly, or
> instead in (2b) about to die the lingering death of small memory leaks, or
> even (2c) some bug in some _unrelated_ subsystem is flaring up. Sort
> of like a stomach ache, if you think about it, but less common.
>
> In sho
On Friday 24 January 2003 21:11, David Brownell wrote:
> Duncan Sands wrote:
> > Can I eliminate the second FILL_BULK_URB? In other words,
> > does the USB subsystem modify any of the parameters touched
> > by FILL_BULK_URB?
>
> On 2.4 you need to restore urb->dev ... that gets cleared to get
> ri
26 matches
Mail list logo
