Looks better ... except that I remembered there's another case
to worry about. For short reads, consider:
The donelist handling would need to handle that; it's
got code to skip the rest of a bulk/intr data stage,
but not code to make sure the control status packet is
still queued.
I think you
> -Original Message-
> From: David Brownell [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 07, 2003 8:13 AM
> To: Christopher Li
> Cc: 'Oliver Neukum '; [EMAIL PROTECTED]
> Subject: Re: [linux-usb-devel] usbdevfs setup URB buffer size limit
>
>
> Christopher Li wrote:
> >
> > Here
Seems like right now only the UHCI code supports timeouts. I've
not been able to persuade myself that it really matters ...
There is one driver using the feature now (stv680.c) and I was trying to
get it into the usbnet.c driver when I noticed the fact it was disabled.
Most drivers do their
On Fri, Feb 07, 2003 at 09:49:52PM +0100, Oliver Neukum wrote:
> Am Freitag, 7. Februar 2003 14:52 schrieb Alan Cox:
> > On Fri, 2003-02-07 at 08:45, Oliver Kurth wrote:
> > > the names depend on the order I plug them in. If I plug in my orinoco
> > > first, it gets eth1, if I plug in the kaweth fi
On Fri, Feb 07, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
> > David, it appears that timeouts aren't even enabled in the OHCI driver
> > because DO_TIMEOUTS is not defined anywhere. Did I miss where it was
> > defined or was this done on purpose?
>
> It's not define
Johannes Erdfelt wrote:
While looking at the driver, I noticed this field was not used anymore.
Trivial patch to remove it.
Right, that must have been _really_ long ago that it was used, too!
(Greg, please merge it when you get back.)
- Dave
JE
# This is a BitKeeper generated patch for th
Johannes Erdfelt wrote:
I've been digging into the OHCI driver to understand and/or fix a couple
of bugs I've been running into and I noticed this comment.
It's not accurate anymore since all 3 HCs use urb->timeout as a relative
value.
Good to know that ... thanks for the patch(es)! (Greg, ple
While looking at the driver, I noticed this field was not used anymore.
Trivial patch to remove it.
JE
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.4 USB kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher
I've been digging into the OHCI driver to understand and/or fix a couple
of bugs I've been running into and I noticed this comment.
It's not accurate anymore since all 3 HCs use urb->timeout as a relative
value.
David, it appears that timeouts aren't even enabled in the OHCI driver
because DO_TIM
Oliver Neukum wrote:
However, the USB subsystem should be doing
try_module_get before any call into a driver. But there is one case in
which it doesn't: calling urb completion handlers. Isn't this wrong?
No. The driver's disconnect method is responsible for unlinking all URBs and
_wait_ for
Oliver Neukum wrote:
* updated ... per-frame irqs gone, status
and feature flags allow hardware handling (as required by
cpus like pxa250), usb suspend/resume aren't exposed, and
"usb_request" did need to have some flag bits declared.
How does the gadget driver learn of o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Freitag, 7. Februar 2003 21:54 schrieb Duncan Sands:
> On Friday 07 February 2003 17:28, Oliver Neukum wrote:
> > > That was a guess - and it seems wrong (I should have taken the 30
> > > seconds needed to check...). I can't in fact see anything th
> * updated ... per-frame irqs gone, status
>and feature flags allow hardware handling (as required by
>cpus like pxa250), usb suspend/resume aren't exposed, and
>"usb_request" did need to have some flag bits declared.
How does the gadget driver learn of of a stalled
On Friday 07 February 2003 17:28, Oliver Neukum wrote:
> > That was a guess - and it seems wrong (I should have taken the 30 seconds
> > needed to check...). I can't in fact see anything that stops the module
> > being unloaded after a successful probe! I assumed that the driver would
>
> That's
Am Freitag, 7. Februar 2003 14:52 schrieb Alan Cox:
> On Fri, 2003-02-07 at 08:45, Oliver Kurth wrote:
> > the names depend on the order I plug them in. If I plug in my orinoco
> > first, it gets eth1, if I plug in the kaweth first, _it_ gets eth1, and
> > the orinoco would get eth2. But I want to
On Fri, 7 Feb 2003 [EMAIL PROTECTED] wrote:
> Subject: Re: [linux-usb-devel] Feature for kaweth.c: setting the device name
> From:Oliver Kurth <[EMAIL PROTECTED]>
..
> > > SIOCSIFNAME handles this generically in the network core
> >=20
> > Very well, therefore I consider this case closed.
>
> Sorr
Hi Sebastien,
I am working with an TI Omap 1510 and a 2.4.15 linux kernel
on an embedded device. I would like to show to my pc the
memory content of my mobile device via the USB port.
I have read some documentation and as far as i know
i have to use the mass storage interface class to
write my
Here's the updated ... if you looked at the
previous version, it's the same basic structure, with cleanups:
* handling of status and feature flags doesn't assume software
can do more than set/clear halt (or self-powered) features.
* per-frame irq capability removed from interface, so driver
This is IMO more interesting/suggestive than just the API
spec, which has been posted before ... it's a driver using
the API! So it lets you see the kinds of issues that a
USB "gadget" driver will need to deal with, and how they're
handled.
Things to notice (and maybe comment on) as you skim this
In late November I posted a draft of a "gadget" API, which would
drive the device-side USB controller hardware as more of those
systems grew smart enough to use Linux inside.
I got some good feedback then, and now seems a good time to provide
an update. It'll be in two followup posts:
* upda
John Homppi wrote:
Thanks for the comments.
Where can I find the test programs that demonstrate output on an interrupt
end-point. An example program would help immensely.
I was just using the "usbtest" driver, in 2.5, with the module
option that told it to stream OUT data using interrupt trans
[EMAIL PROTECTED] wrote:
> I think it's pratically impossible to remove/cancel/erase/unlink
> an URB submition from its completition handler so that the handler
> itself will _never_ be called.
I think that didn't translate right to English ... if the handler
weren't called in the first place, it
Hi
I am working with an TI Omap 1510 and a 2.4.15 linux kernel
on an embedded device. I would like to show to my pc the
memory content of my mobile device via the USB port.
I have read some documentation and as far as i know
i have to use the mass storage interface class to
write my device side
Hi,
- probe function is called, driver is bound to an interface
- (driver cannot be unloaded now - this is done in sysfs, no?)
Just what does sysfs do here? So far as I am aware, it does nothing to
prevent the driver from being unloaded. And if it does do something, how
does the user tell it
Duncan:
My knowledge of sysfs is very sketchy, at best. I've read the stuff in
the Documentation directory, but I haven't looked at the code so I don't
know how it works in practice.
On Fri, 7 Feb 2003, Duncan Sands wrote:
> > > - driver (module) registers with USB subsystem
> > > - probe fun
> That was a guess - and it seems wrong (I should have taken the 30 seconds
> needed to check...). I can't in fact see anything that stops the module
> being unloaded after a successful probe! I assumed that the driver would
That's right. A driver can be unloaded even if it is bound to a device
Christopher Li wrote:
Here is the update version of the patch.
Looks better ... except that I remembered there's another case
to worry about. For short reads, consider:
- host says "give me the whole descriptor, here's
a 64KB-1 byte buffer" (16 data TDs).
- device says "ok, here you go,
Hi Alan,
On Friday 07 February 2003 16:20, Alan Stern wrote:
> I too would appreciate getting some good answers to these questions. My
> current understanding is limited (and quite likely wrong at some points).
>
> On Fri, 7 Feb 2003, Duncan Sands wrote:
> > It seems to me that the following is p
I too would appreciate getting some good answers to these questions. My
current understanding is limited (and quite likely wrong at some points).
On Fri, 7 Feb 2003, Duncan Sands wrote:
> It seems to me that the following is possible:
>
> - driver (module) registers with USB subsystem
> - prob
On Thu, 2003-02-06 at 21:46, rahul shetty wrote:
> We are writing a usb device driver for a webcam(twinkle). We are
> encountering a host of problems in writing the read entry point.
> We have opted for isochronous transfer
Unless you designed the webcam yourself and are in control of its
behav
Hi Wolfgang,
Thanks for the comments.
Just to clarify my assumptions, is the following a valid approach?
1) Use usb_fill_int_urb in my own driver to build a URB
2) Use usb_submit_urb to pass the URB to the USB core routines
3) Use a wait queue to await URB completion
4) (as you already stated) u
On Fri, 2003-02-07 at 08:45, Oliver Kurth wrote:
> the names depend on the order I plug them in. If I plug in my orinoco
> first, it gets eth1, if I plug in the kaweth first, _it_ gets eth1, and
> the orinoco would get eth2. But I want to know which sort of device I
> have, so that I can configure
It seems to me that the following is possible:
- driver (module) registers with USB subsystem
- probe function is called, driver is bound to an interface
- (driver cannot be unloaded now - this is done in sysfs, no?)
- driver fires some urbs
- disconnect is called
in disconnect driver call
I think it's pratically impossible to remove/cancel/erase/unlink an URB submition from
its completition handler so that the handler itself will _never_ be called. I tried
everything but the system crashes with no kernel messages (!) and the usb_unlink_urb
is the problem. I tried putting urb->nex
On Thu, Feb 06, 2003 at 11:05:06PM +0100, Oliver Neukum wrote:
> Am Donnerstag, 6. Februar 2003 23:32 schrieb Alan Cox:
> > On Thu, 2003-02-06 at 19:21, Oliver Kurth wrote:
> > > Hello again,
> > >
> > > not as important as my last patch, but I think it's useful, especially
> > > for hotpluggable d
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 the
new fields (plus cleaned up a bit). I couldn't resist a real code change while I was
there: freeing the memory used by the ATM after s
Eliminate a pile of code that isn't used anymore now the new send code
is in place, and make some cosmetic changes. You got this one but it
didn't apply.
atmsar.c | 286 ---
atmsar.h |8 -
speedtouch.c | 42 +++-
3 files
Let's not forget to update the ATM transmission statistics! And
let's not pretend to support AAL0 when we don't. You got this one
but it didn't apply.
speedtouch.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/mis
Expose some CRC definitions in atmsar.h (for use by speedtouch.c).
atmsar.c |3 ---
atmsar.h |7 +++
2 files changed, 7 insertions(+), 3 deletions(-)
diff -Nru a/drivers/usb/misc/atmsar.c b/drivers/usb/misc/atmsar.c
--- a/drivers/usb/misc/atmsar.c Wed Feb 5 16:22:25 2003
+++ b/dri
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, various
bits of info about the AAL5/ATM structure need to be stored beforehand in the skb.
This is done by udsl_groom_skb using the udsl
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 in a series of ATM cells. Finally, the result has to be sent to the modem.
When we have finished with the skb, we nee
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.
speedtouch.c | 18 ++
1 files changed, 18 insertions(+)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--
Measure the receive buffer size in ATM cells (53 bytes).
speedtouch.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Wed Feb 5 16:18:30 2003
+++ b/drivers/usb
This is the first of 10 patches that clean up
packet transmission. For some reason you only
got patches 1, 9 and 10 when I first sent them.
Needless to say 9 and 10 did not apply!
Get rid of some unused #defines.
You got and applied this one.
speedtouch.c |3 ---
1 files changed, 3 deletio
Rename UDSL_RECEIVE_BUFFER_SIZE to UDSL_RCV_BUFFER_SIZE.
speedtouch.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Wed Feb 5 16:15:02 2003
+++ b/drivers/usb
45 matches
Mail list logo
