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 work.
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 (ie it hits 0
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 today
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 really
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.
From
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 really care.
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 it?
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
hardly
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 implement
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 and
It means that the device is physically gone, that's it. What the driver
wants to do with this information is up to it. But the core has to
handle attempts to use this device after it is gone, like it now does.
That's an interesting model, but it doesn't seem to handle some
current
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 there not both
While the subject is in the air, how about device resets? They can be
initiated by a driver bound to any interface, but they affect the whole
device.
A sore spot.
I don't know enough about how the core handles resets... the device needs
to be re-configured (USB address assigned, etc.),
A better way to say it may be: if that's not what disconnect()
means, than what the heck _does_ it mean? There are a whole LOT
of answers in current use. Clearly the idea is to prohibit some
kinds of behavior. Which ones? And why _not_ all of them?
It means that the device is
The only time a driver would need to get a reference is if it intends to
use the device structure past the disconnect() callback.
The question should be, what a reference may be used for after disconnect().
To determine requirements we must look at the worst case. In this case
this is
Am Montag, 24. Februar 2003 10:58 schrieb Duncan Sands:
Output the correct device name, show the state of the device (for
debugging) and of the ADSL line (anyone want to write a graphical utility
to show this, like under windows?). We no longer consult the usb_device
struct in
Am Dienstag, 25. Februar 2003 19:24 schrieb Josh Myer:
Attached are drivers for the KB Gear JamStudio Tablet. There are two
files, one is against 2.4.20, the other against 2.5.62. I'm hoping this
isn't too late in the 2.4.21-pre stages to get included (or the 2.5, for
that matter =). This
If I load the kernel USB driver, the scanner is detected by it, but
accessing /dev/usb/scanner0 fails.
With devfs enabled or dynmic minors disabled everything works as
expected.
Which minor is allocated?
Regards
Oliver
So in practice disconnect() means a cold, hard stop using that
device.
Is that really to be expected?
How often do admins change device drivers? In 99% of the cases, there's
only one device driver.
The same is true for configuration changes. Anyway the point is moot.
Am Mittwoch, 26. Februar 2003 05:18 schrieb David Brownell:
Yes, a configuration change is:
1. Lock device
2. Disconnect all interfaces
3. Send control message
4. Unlock device
5. Probe all the device's interfaces
To a driver changing a configuration is an unplug, replug cycle.
Yes, but I think that you should notify the network layer too.
I see no reason any network driver shouldn't report this directly.
There's nothing specific to ATM in losing signal.
It's purely physical thing low level drivers should deal with.
I can't notify the network layer because
Hi Oliver, thanks for your comments. While I agree with you in
principle, I disagree in practice. The driver exports the following
information in /proc/net/atm/speedtch:
(1) name and location of the USB device
(2) MAC address (serial number)
(3) AAL5 transmission statistics
(4) Line
I did create a device node manually (180/0) for testing. Maybe there
was a typo in the mknod command or something like that. Now it works.
Same for the libusb trouble. No problems anymore, even with dynamic
minors turned on and devfs turned off.
Just ignore my report :-)
It's more or
That's the reason it doesn't work. You need hotplug scripts that make
the device node. Unfortunately that's a race that causes insecurity.
Not true at all. What's the race?
plug in device
attach to device node
script runs and adjusts permissions - so far so good
some time passes
device
Am Mittwoch, 26. Februar 2003 20:14 schrieb Greg KH:
On Wed, Feb 26, 2003 at 08:16:05PM +, Alan Cox wrote:
On Wed, 2003-02-26 at 18:24, Greg KH wrote:
That's the reason it doesn't work. You need hotplug scripts that make
the device node. Unfortunately that's a race that causes
Oopsing is undesirable, true, but is one of the consequences of
not implementing disconnect() right. And it has the advantage
of not facilitating the subtle falure modes coming from components
having different notions of device (or interface) state.
The the host controller driver
The the host controller driver should be fixed. This is because some
drivers don't even know about all of the urbs they have submitted
(visor driver being one of them), so they can't know to cancel them :)
These drivers are buggy, plain and simple.
No, the USB core is buggy if
You can argue it both ways all day. Either approach needs routines to keep
a linked list of urbs. At that point it doesnt matter if the list is kept
by the driver or the core just so long as it is clear who owns the relevant
list_entry structure at all times.
There are good arguments for it
Am Samstag, 1. März 2003 18:18 schrieb Alan Cox:
On Sat, 2003-03-01 at 10:13, Oliver Neukum wrote:
The other is that the driver already must have code to make sure that
there are no further submissions after disconnect(). The core cannot
enforce that.
If you always did disconnect
Am Donnerstag, 6. März 2003 12:19 schrieb Tvrtko A. Ursulin:
Hi everyone,
Under 2.4 : If I submit a receive urb in probe(). Can it's completion
callback be called before probe() finishes?
Yes.
HTH
Oliver
---
This
Am Montag, 10. März 2003 13:59 schrieb Duncan Sands:
Hi all, must the transfer_buffer I provide with an urb be
aligned on, say, a double-word boundary or something like
that?
The alignment requirements are specific to the hardware that happens
to be used. kmalloc() will return properly aligned
Am Dienstag, 11. März 2003 10:57 schrieb Oliver Kurth:
Hi again,
is someone taking care of this patch? I do not want it to be lost.
Unless I am mistaken it has been applied to Greg's 2.4 tree.
I'll do a 2.5 version soon.
Regards
Oliver N.
Am Dienstag, 11. März 2003 16:43 schrieben Sie:
On Monday 10 March 2003 7:36 pm, Oliver Neukum wrote:
Am Montag, 10. März 2003 13:59 schrieb Duncan Sands:
Hi all, must the transfer_buffer I provide with an urb be
aligned on, say, a double-word boundary or something like
And as near as I can tell, nobody has ever needed usb_unlink_one()
like we have today, except as a way to build usb_unlink_all().
How about SCSI abort and network timeout ?
Regards
Oliver
---
This SF.net email is
Am Donnerstag, 13. März 2003 00:23 schrieb David Brownell:
Oliver Neukum wrote:
And as near as I can tell, nobody has ever needed usb_unlink_one()
like we have today, except as a way to build usb_unlink_all().
How about SCSI abort and network timeout ?
SCSI abort applies to one request
Hi Greg,
you recently asked whether the module pointers could be removed.
I looked at the question and the answers is that they cannot be removed.
The ioctl into the driver through usbfs makes that impossible.
Sorry
Oliver
Hi,
am I right in assuming that any disconnects/probes _must_ be done through
driver core? Or is calling usb_device_remove() directly still legal?
Regards
Oliver
---
This SF.net email is sponsored by:Crypto Challenge
Am Montag, 17. März 2003 21:09 schrieb David Brownell:
You know, in all this email I think one of the key issues
has somehow not gotten brought out: the need to let the
I/O requests get canceled when the task gets signaled.
Or at least having an option to do that.
You mean signalled as in
What's wrong with using the fine macros provided in 2.5 to sleep with
TASK_INTERRUPTIBLE and unlink in the interruption case?
The current synchronous calls force TASK_UNINTERRUPTIBLE,
and I don't know what macros you're talking about that
would do all that. Is there some other
Hi,
some part of the synchronous API is used in the block io error handling
code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL.
Greg, please apply.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to
Am Dienstag, 18. März 2003 16:12 schrieb Alan Stern:
On Tue, 18 Mar 2003, Oliver Neukum wrote:
Hi,
some part of the synchronous API is used in the block io error handling
code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL.
Greg, please apply.
Oliver, is this meant to refer
Should we simply add a flag to the synchronous calls or add
interruptible versions?
Aren't those two options identical? Both are API syntax changes. :)
I agree with David's proposal above; just make usb_bulk_msg() and
usb_control_msg() interruptible. But what about synchronous
Am Dienstag, 18. März 2003 20:03 schrieb Alan Stern:
On Tue, 18 Mar 2003, Oliver Neukum wrote:
I agree with David's proposal above; just make usb_bulk_msg() and
usb_control_msg() interruptible. But what about synchronous
usb_unlink_urb()?
IMHO that's not a good idea. If we change
How can that be? The SCSI layer guarantees that no further requests are
issued while the error handler is running.
Yes. The synchronous API calls you are concerned about are made from a
subroutine that is called directly by the error handler and that runs in
the context of the error
Hi Dave,
does this remove your doubts about race conditions in the synchronous API?
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
Am Mittwoch, 19. März 2003 22:00 schrieb Pete Zaitcev:
From: Oliver Neukum [EMAIL PROTECTED]
Date: Wed, 19 Mar 2003 21:44:10 +0100
+#define __wait_event_timeout(wq, condition, ret) \
+ if (condition
Am Donnerstag, 20. März 2003 01:04 schrieb Matthew Dharm:
I'm not certain this is a problem...
I know blocking is legal in the SCSI error-handling context. Other I/O
will continue during this time.
Blocking as such is OK. Blocking on IO that is waiting for your own device
to process IO
Am Mittwoch, 19. März 2003 23:39 schrieb David Brownell:
Oliver Neukum wrote:
Hi Dave,
does this remove your doubts about race conditions in the synchronous
API?
It's a lot closer ... I'll try it. Yes, it's odd that there
was no pre-existing wait_event_timeout(), and that's the
call
Am Mittwoch, 19. Mrz 2003 23:29 schrieb [EMAIL PROTECTED]:
Hi,
First, this seems to be a reproducible oops. Second, the kernel oops
messages, ksymoops outputs and some other stuff I thought might be of
use, can be found at
http://stekt.oulu.fi/~flexy/Oops.tar
Then, about my hardware,
Am Donnerstag, 20. März 2003 17:03 schrieb Alan Stern:
On Thu, 20 Mar 2003, Oliver Neukum wrote:
were doing it, I'd not use the synchronous unlink call;
ought not to matter, but we can be more sure than that.
That's dangerous. We must have absolute confidence about whether
the message
I've actually been thinking along those lines, too... but, given the new
design where devices aren't 'remembered', doing the above would disconnect
a device and create a new one (as seen by the user). It kinda defeats the
entire purpose of the reset (which is to try to get back to a good
whiteheat.c
whiteheat_attach:
usb_clear_halt(serial-dev, pipe);
ret = usb_bulk_msg (serial-dev, pipe, command, sizeof(command), alen,
COMMAND_TIMEOUT);
DMA on stack
whiteheat_write:
result = usb_submit_urb(urb, GFP_ATOMIC);
no need for ATOMIC here
Am Mittwoch, 19. März 2003 23:46 schrieb Greg KH:
On Fri, Mar 14, 2003 at 07:56:27AM -0800, David Brownell wrote:
Oliver Neukum wrote:
am I right in assuming that any disconnects/probes _must_ be done
through driver core? Or is calling usb_device_remove() directly still
legal?
I'm
Hi,
here for for convinience the patches that should reasonably fix the
problem. Matt, shall they go in?
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
Hi,
driver core protects us with semaphores during probe/disconnect. We can
stop messing with the module usage counts.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
Hi,
this won't be quite to Greg's liking as it introduces holding another
semaphore, but it is needed. You must not probe and reset at the same time.
This can best be assured by the device's semaphore.
Regards
Oliver
You can import this changeset into BK by piping this
Am Donnerstag, 27. März 2003 01:54 schrieb Greg KH:
On Wed, Mar 26, 2003 at 11:02:43PM +0100, Oliver Neukum wrote:
Hi,
this won't be quite to Greg's liking as it introduces holding another
semaphore, but it is needed. You must not probe and reset at the same
time. This can best
Am Donnerstag, 27. März 2003 08:34 schrieb Duncan Sands:
driver core protects us with semaphores during probe/disconnect. We can
stop messing with the module usage counts.
Hi Oliver, you are assuming
(1) that usb_register is called within the module, and not on its behalf by
eg a
Well I asked Pat, and he said it was ok to use.
I'd prefer that, as we would not have to grab yet-another-lock in the
probe sequence. Just document it well :)
Here it is. This time locking and doing the operation is seperated.
Some firmware loaders need to do a reset during probe.
Hi,
looking into cdc-acm it seems to me that the driver simply iterates over
all available configurations and switches to them. Isn't that obviously
buggy, as their may be already other drivers bound to other interfaces
of the device ?
Regards
Oliver
Hi Alan, Thomas,
could you tell me why this piece of code is in audio_probe() ?
if (usb_set_configuration(dev, config-desc.bConfigurationValue) 0) {
printk(KERN_ERR usbaudio: set_configuration failed (ConfigValue
0x%x)\n, config-desc.bConfigurationValue);
Hi,
these calls either are unnecessary or harmful.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
Hi,
is the following code from storage_probe() necessary:
#ifdef CONFIG_USB_STORAGE_SDDR09
if (protocol == US_PR_EUSB_SDDR09 || protocol == US_PR_DPCM_USB) {
/* set the configuration -- STALL is an acceptable response here */
result =
Am Freitag, 4. April 2003 22:07 schrieb Subrata Goswami:
Hi, have two simple questions.
1. If there are multiple driver modules (*.o) for a single USB device,
what precedence would be followed while loading them ? The
/etc/modules.conf file does not contain any of the drivers.
2. What part
That helps. So a buffer used for device input should be allocated
separately from anything written by the CPU, whereas a buffer used for
device output can be shared with other data in a buffer allocated by
kmalloc, but not on the stack.
Judging by this implementation from mips Doing so
Am Donnerstag, 5. Juni 2003 21:53 schrieb Alan Stern:
On Thu, 5 Jun 2003, Oliver Neukum wrote:
That helps. So a buffer used for device input should be allocated
separately from anything written by the CPU, whereas a buffer used for
device output can be shared with other data in a buffer
Am Donnerstag, 5. Juni 2003 22:16 schrieb David Brownell:
This patch:
- moves the config-specific sysfs updates out of
usb_new_device() into usb_set_configuration(),
where it belongs.
- makes usb_set_configuration() get rid of sysfs
state for the previous configuration,
2. You can set hubs to config 0. What will that do?
You can set anything to config 0 -- perfectly reasonable.
I take it you're suggesting that hubs are special enough
that allowing that to happen would be a Bad Thing?
Makes sense to me. Suggestion?
I take that back. Your implementation
Sorry, I misspoke in my original message. I didn't mean
usb_reset_config(); I was thinking about drivers that want to change to a
different configuration during their probe(). How do you plan to
accomodate that?
Let the perverts use a workqueue.
Regards
Oliver
The second restriction is that some architectures don't maintain their
cache coherently when DMA takes place. This means that input buffers
_must_ be allocated in a region containing no data the CPU will touch
during the input operation. For if the CPU touches data D lying in the
same
Am Freitag, 6. Juni 2003 22:51 schrieb Alan Stern:
This revised version of my earlier patch allocates the transfer buffers
correctly.
Since the hub driver is kind of exemplary, how about using
usb_buffer_alloc() ?
Regards
Oliver
Hi David,
you wrote:
- Devices on some EHCI controllers could handle DMA to/from high memory.
Driver probe() routines can notice this using a generic DMA call, then
tell higher level code (network, scsi, etc) about it like this:
if (dma_supported (intf-dev, 0xULL))
Am Dienstag, 27. Mai 2003 22:35 schrieb David Brownell:
Alan Stern wrote:
I want to propose a reorganization of the way the USB core handles device
resets, configuration changes, connects, and disconnects. The motivation
for this is to fix a number of weaknesses in the way device resets
Am Dienstag, 27. Mai 2003 22:41 schrieb Alan Stern:
Until my ambitious project gets going, this patch at least fixes the
problem of assigning a device's new address following a device reset.
The only change needed to David's original suggestion was to handle the
pathway involved in registering
I've thrown up a new rev of the driver that now includes some basic
ethtool mii-tool support. The mii output isn't quite correct just
yet, but it does know link status which helps with RedHat init scripts
so it knows whether or not to run DHCP.
Am Donnerstag, 29. Mai 2003 18:22 schrieb Alan Stern:
On Thu, 29 May 2003, Oliver Neukum wrote:
Device reset is a partial re-enmeration. I suspect some
of the issues there would go better if it were more of
a full re-enumeration (you said something similar). And
again, that's
+ /* Normally the current state is RUNNING. If the control thread
+* hasn't even started processing this command, the state will be
+* IDLE. Anything else is a bug. */
+ if (state != US_STATE_RUNNING state != US_STATE_IDLE) {
+ printk(KERN_ERR
Hi,
this allows us to learn about a port that cannot be disabled. It's needed
for a superrobust usb_reset_device(). Please apply.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch
Are we talking about the same thing here? In my original message I was
describing the usb_device_altered() function, which we expect a driver to
call after it has called usb_device_reset(). The reset() call rebinds all
the drivers to the interfaces they had before the reset, explicitly
2. Reset should not mean disconnecting the other interfaces. The
properties internal to the drivers of the other interfaces should be
retained and restored. Suspend/resume is the correct model, not
disconnect/probe. Kicking off all drivers but restoring the altsettings
like we do is
Am Dienstag, 3. Juni 2003 22:59 schrieb Alan Stern:
I've been told it's not a good idea to put transfer buffers on the stack,
as that's not DMA-able on some architectures. Nevertheless, it's done in
the USB core (well, I found one place in hub.c that does it -- but that's
after only 1 minute
Hi,
setting the configuration is pointless in dabusb, isn't it?
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
Hi Greg,
this cuts out old cruft.
Please apply.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
Hi,
you always set the same configuration. This makes doing so quite pointless.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
Hi,
you should not drop errors.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[EMAIL
Hi,
going through the drivers, it seems that there are drivers which legitimately
use usb_set_configuration. It seems that we have to deal with it.
Some drivers, cdc-acm, -ether, really take the whole device and try
all configurations.
Some like empeg and other serial drivers use it where
--- 1.17/drivers/usb/core/hub.h Mon Oct 7 16:26:34 2002
+++ edited/drivers/usb/core/hub.h Wed Jun 4 10:37:30 2003
@@ -175,6 +175,10 @@
/* buffer for urb ... 1 bit each for hub and children, rounded up */
charbuffer[(USB_MAXCHILDREN + 1 + 7) / 8];
As for cdc-acm, I don't think it should be doing that. The code
that chooses a configuration can reasonably change its mind, for
example if there was a choice and no driver could bind to that
initial selection ... I don't think probe() should be allowed
to change configurations.
To
Am Mittwoch, 4. Juni 2003 20:58 schrieb Alan Stern:
On Wed, 4 Jun 2003, Oliver Neukum wrote:
It seems to me that this union needs a cacheline of its own for
noncoherent architectures. The rest looks good.
Oliver:
I would appreciate it if you (or anyone else) could post or provide
You're looking at the question from the inside out, as an OS
developer. I think you could benefit from a reverse perspective,
from the standpoint of the peripheral manufacturers and driver
developers. They have very different concerns.
Just some thoughts.
Quite sensible thoughts.
What
Am Donnerstag, 5. Juni 2003 00:26 schrieb [EMAIL PROTECTED]:
Hi,
you always set the same configuration. This makes doing so quite
pointless.
Regards
Oliver
Pardon the interruption, but I don't believe you can arbitrarily remove
device writes just because they appear to be
I like the configuration driver idea, though I submit it should be an
integral part of the device driver rather than a separate component.
This is just based on a question of system maintenance over time.
It's much easier if you have one file responsible for one device.
Likely it'd be
A device may have several interfaces in its configurations. Which driver
shall decide? And who shall decide which driver is to decide?
A good example of a manufactured problem. In my proposal, there is only
one driver for a given device, so your questions disappear.
The number of device
Hi,
in kaweth I get from init_etherdev a device with the name 'ACTION=add'.
Is this a known brokenness?
Regards
Oliver
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on
Am Montag, 9. Juni 2003 02:33 schrieb Greg KH:
On Sun, Jun 08, 2003 at 02:25:59PM -0700, Matthew Dharm wrote:
Greg, when is the next BK pull from the Linus tree going to happen?
Normally, you seem to pull after a release, but since those are getting
farther and farther apart
Because
Hi Greg,
this changes kaweth to use usb_buffer_alloc in the control
and recieve paths, in which it is using fixed buffers which
are not safe on some architectures. As a plus, it should
get a little faster on some architectures.
Please apply.
Regards
Oliver
You can import
Am Samstag, 14. Juni 2003 01:34 schrieb Greg KH:
On Thu, Jun 12, 2003 at 09:27:38AM +0200, Oliver Neukum wrote:
Hi Greg,
this changes kaweth to use usb_buffer_alloc in the control
and recieve paths, in which it is using fixed buffers which
are not safe on some architectures. As a plus
Am Sonntag, 15. Juni 2003 14:24 schrieb [EMAIL PROTECTED]:
Hi, folks
I have a question. I have an idea about a device. This device can be
considered as a black box which includes a Linux OS and one or more
harddisks that can be controled(read and write) by the embedded Linux OS. I
want the
Am Montag, 16. Juni 2003 21:02 schrieb Greg KH:
On Sat, Jun 14, 2003 at 12:21:14PM +0200, Oliver Neukum wrote:
Am Samstag, 14. Juni 2003 01:34 schrieb Greg KH:
On Thu, Jun 12, 2003 at 09:27:38AM +0200, Oliver Neukum wrote:
Hi Greg,
this changes kaweth to use usb_buffer_alloc
Am Montag, 16. Juni 2003 21:02 schrieb Greg KH:
On Sat, Jun 14, 2003 at 12:21:14PM +0200, Oliver Neukum wrote:
Am Samstag, 14. Juni 2003 01:34 schrieb Greg KH:
On Thu, Jun 12, 2003 at 09:27:38AM +0200, Oliver Neukum wrote:
Hi Greg,
this changes kaweth to use usb_buffer_alloc
1 - 100 of 2709 matches
Mail list logo
