Oliver Neukum schrieb:
Am Dienstag, 15. Mai 2007 16:43 schrieb Robert Marquardt:
Oliver Neukum schrieb:
The main problem implementing this is LEDs. HID has the very though
property of initiating output to them without user space's involvement
from interrupt context to all attached devices.
David Brownell wrote:
On Sunday 13 May 2007, Tzachi Perelstein wrote:
Hello,
I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has
a PCI/PCIE interfaces as well as an integrated USB controller.
While looking at ehci-hcd.c it looks like there's some kind of dependency
On Tue, May 15, 2007 at 03:32:18PM -0700, Lucy McCoy wrote:
Add support for Keyspan adapters: USA-49WG and USA-28XG
Yeah! Thanks for doing this, I was beginning to wonder about these
devices as I had a few users ask about them recently.
Signed-off-by: Lucy P. McCoy [EMAIL PROTECTED]
---
Am Mittwoch, 16. Mai 2007 08:41 schrieb Robert Marquardt:
Oliver Neukum schrieb:
Am Dienstag, 15. Mai 2007 16:43 schrieb Robert Marquardt:
Oliver Neukum schrieb:
The main problem implementing this is LEDs. HID has the very though
property of initiating output to them without user
Oliver Neukum schrieb:
Writing reports to a device from kernel? Why would that be needed?
It is in my experience mainly needed for setting and clearing the LEDs.
But I don't claim to know all input devices in the kernel tree.
Does hat really have to be handled on low-level? It should be
Am Mittwoch, 16. Mai 2007 10:24 schrieb Robert Marquardt:
Oliver Neukum schrieb:
Writing reports to a device from kernel? Why would that be needed?
It is in my experience mainly needed for setting and clearing the LEDs.
But I don't claim to know all input devices in the kernel tree.
On Wed, 16 May 2007, Robert Marquardt wrote:
Writing reports to a device from kernel? Why would that be needed?
It is in my experience mainly needed for setting and clearing the LEDs.
But I don't claim to know all input devices in the kernel tree.
Does hat really have to be handled on
On Tue, 15 May 2007, Oliver Neukum wrote:
this is autosuspend for HID devices. It uses the new last_busy facility
for USB devices. And for a few functions the pm counter.
Hi Oliver,
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the
Jiri Kosina schrieb:
first, why did you remove me from CC when responding?
Sorry, on too many lists with widely varying reply rules. Just goofed.
Anyway, what would be your proposal here? Currently the output reports
(for changing the keyboard LEDs, for example) are being submitted as soon
Am Mittwoch, 16. Mai 2007 11:24 schrieb Jiri Kosina:
On Tue, 15 May 2007, Oliver Neukum wrote:
this is autosuspend for HID devices. It uses the new last_busy facility
for USB devices. And for a few functions the pm counter.
Hi Oliver,
just a quick immediate note - I just tested it on
On Wed, 16 May 2007, Robert Marquardt wrote:
Anyway, what would be your proposal here? Currently the output reports
(for changing the keyboard LEDs, for example) are being submitted as
soon as the corresponding input event occurs (on different keyboard),
which makes sense. Could you be
Am Mittwoch, 16. Mai 2007 11:24 schrieb Jiri Kosina:
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the USB keyboard still seems to be awake
(leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order
to suspend it
On Wed, 16 May 2007, Oliver Neukum wrote:
just a quick immediate note - I just tested it on my testing box, and
it doesn't seem to work for me - the USB keyboard still seems to be
awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs
in order to suspend it immediately.
On Wed, 16 May 2007, Oliver Neukum wrote:
And as a sanity check, please check with lsusb whether your keyboard can
do remote wakeup. I've never seen one that doesn't but it is within
spec.
Suspending of this keyboard used to work with older versions of your
patches you sent me some
Jiri Kosina schrieb:
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the USB keyboard still seems to be awake
(leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order
to suspend it immediately.
Ah, that was nagging
On Wed, 16 May 2007, Robert Marquardt wrote:
just a quick immediate note - I just tested it on my testing box, and
it doesn't seem to work for me - the USB keyboard still seems to be
awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs
in order to suspend it
Am Mittwoch, 16. Mai 2007 11:41 schrieb Jiri Kosina:
On Wed, 16 May 2007, Oliver Neukum wrote:
And as a sanity check, please check with lsusb whether your keyboard can
do remote wakeup. I've never seen one that doesn't but it is within
spec.
Suspending of this keyboard used to work
Am Mittwoch, 16. Mai 2007 11:40 schrieb Robert Marquardt:
Jiri Kosina schrieb:
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the USB keyboard still seems to be awake
(leds are on), even if I echo 0 into 'autosuspend' file in sysfs
Am Mittwoch, 16. Mai 2007 11:48 schrieb Jiri Kosina:
On Wed, 16 May 2007, Robert Marquardt wrote:
just a quick immediate note - I just tested it on my testing box, and
it doesn't seem to work for me - the USB keyboard still seems to be
awake (leds are on), even if I echo 0 into
Oliver Neukum schrieb:
Am Mittwoch, 16. Mai 2007 11:40 schrieb Robert Marquardt:
Jiri Kosina schrieb:
just a quick immediate note - I just tested it on my testing box, and it
doesn't seem to work for me - the USB keyboard still seems to be awake
(leds are on), even if I echo 0 into
On Wed, 16 May 2007, Oliver Neukum wrote:
Actually, there's currently a race in the code that can trigger if you
It is my understanding that a PID effect can be active long after the
message went out to the device. Is that correct?
Yes, I am afraid you can't assume that the effect playback
Am Dienstag, 15. Mai 2007 16:37 schrieb Alan Stern:
Can you break this up into two patches? If the first adds the queuing
code and the second adds autosuspend support, it will be much easier to
appraise and test them.
Here's part #2, the core autosuspend.
Regards
Am Mittwoch, 16. Mai 2007 12:01 schrieb Robert Marquardt:
A suspended bus-powered USB device cannot drive LEDs so suspending an
USB keyboard with CAPS LOCK on means it gets out of sync.
How much power does an LED need? You have 2mA in suspended mode.
A standard LED uses about 20 mA
Hi Alan, list,
here's the patch to introduce anchors for use with fire-and-forget
techniques and a modification for the skeleton driver to use them.
This should make implementing pre/post_reset and suspend/resume
much easier.
Regards
Oliver
--
--- a/include/linux/usb.h
Hi,
here's an additional device with the reset quirk.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/bluetooth/hci_usb.c 2007-05-15 14:09:55.0 +0200
+++ b/drivers/bluetooth/hci_usb.c 2007-05-16 07:50:16.0 +0200
Hi Oliver,
here's an additional device with the reset quirk.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
that patch doesn't apply since we already have this:
/* Dell laptop with Broadcom chip */
{ USB_DEVICE(0x413c, 0x8126),
Am Mittwoch, 16. Mai 2007 13:50 schrieb Marcel Holtmann:
Hi Oliver,
here's an additional device with the reset quirk.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
that patch doesn't apply since we already have this:
/* Dell laptop with
Hi Oliver,
here's an additional device with the reset quirk.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
that patch doesn't apply since we already have this:
/* Dell laptop with Broadcom chip */
{ USB_DEVICE(0x413c,
A user reported that his dongle needs a reset to work. A manual reset, the
module option and that patch solved the issue.
an manual reset is not possible. The HCI_RESET quirk only end up sending
HCI Reset as the first command. This actually only resets the Bluetooth
chip and nothing on
Hi Oliver,
A user reported that his dongle needs a reset to work. A manual reset, the
module option and that patch solved the issue.
an manual reset is not possible. The HCI_RESET quirk only end up sending
HCI Reset as the first command. This actually only resets the Bluetooth
chip
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
The main issue is that DMA'able memory is allocated per USB host controller on
Linux and not per USB host controller and pipe
On Wed, 16 May 2007, Oliver Neukum wrote:
Suspending of this keyboard used to work with older versions of your
patches you sent me some weeks/months ago.
Yes, then it should keep working. My keyboard does suspend.
Could you post your syslog?
I have had also one very strange (and broken in
On Wed, 16 May 2007 07:37:04 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
+ /* Task context for reporting idleness */
+ struct work_struct idle_work;
This does not seem to be used anywhere.
I did not verify the function in detail, but the patch looks sane at
a quick glance.
-- Pete
On Wed, 16 May 2007, Pete Zaitcev wrote:
I did not verify the function in detail, but the patch looks sane at a
quick glance.
Hi Pete and Oliver,
(BTW, why was I again dropped from CC? :) )
I consider the things below crucial before this could be merged:
- what to do with devices with
On Wed, 16 May 2007 14:49:37 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
I think that what you described is largely
On Tue, 15 May 2007, Laurent Pinchart wrote:
Hi everybody,
following the discussion about the split bulk transfers, Alan Stern and David
Brownell told me I shouldn't use usb_buffer_alloc as a generic purpose URB
buffer allocated. However, Documentation/usb/dma.txt contradicts this. Should
On Wed, 16 May 2007, Oliver Neukum wrote:
Am Dienstag, 15. Mai 2007 23:49 schrieb Alan Stern:
On Tue, 15 May 2007, Oliver Neukum wrote:
I think we're getting off the point here. Suppose the usbhid driver
gets a powerloss_resume call for a mouse. What do you want it to do
that we
Hi,
Interesting reading.
On Wednesday 16 May 2007 16:08, Pete Zaitcev wrote:
On Wed, 16 May 2007 14:49:37 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
...
What I would suggest is that when you allocate an URB and
On Wednesday 16 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 11:40 schrieb Robert Marquardt:
A suspended bus-powered USB device cannot drive LEDs so suspending an
USB keyboard with CAPS LOCK on means it gets out of sync.
How much power does an LED need? You have 2mA in
On Tuesday 15 May 2007, Laurent Pinchart wrote:
Hi everybody,
following the discussion about the split bulk transfers, Alan Stern and David
Brownell told me I shouldn't use usb_buffer_alloc as a generic purpose URB
buffer allocated. However, Documentation/usb/dma.txt contradicts this.
On Wednesday 16 May 2007 16:41, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to
its API design.
...
On Wed, 16 May 2007, Pete Zaitcev wrote:
What I would suggest is that when you allocate an URB and DMA'able memory,
you
have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC} it belongs to.
What do you think?
Just a side note, we are trying to move away from the pipe as a
On Wed, 16 May 2007 07:41:26 -0700, David Brownell [EMAIL PROTECTED] wrote:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you will
never get in the situation of not being able to allocate transfer
descriptors
on the fly, like done on
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
On the BSD platform there is something called BUS-DMA. Memory is allocated
according to PCI device capabilities. This is because sometimes the PCI
device is not capable of addressing the complete memory. Also you need to
sync memory,
On Wed, 16 May 2007, Oliver Neukum wrote:
Here's part #2, the core autosuspend.
@@ -230,12 +239,14 @@ static void hid_irq_in(struct urb *urb)
switch (urb-status) {
case 0: /* success */
+ usbhid_mark_busy(usbhid);
On Wednesday 16 May 2007, Pete Zaitcev wrote:
On Wed, 16 May 2007 07:41:26 -0700, David Brownell [EMAIL PROTECTED] wrote:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will
never get in the situation of not being able to allocate
On Wed, 16 May 2007, Oliver Neukum wrote:
Hi Alan, list,
here's the patch to introduce anchors for use with fire-and-forget
techniques and a modification for the skeleton driver to use them.
This should make implementing pre/post_reset and suspend/resume
much easier.
This won't build
On Wed, 16 May 2007, David Brownell wrote:
I have never, ever, seen USB stack deplete the atomic pool completely
either, if this is what you are talking about. So, you're quite right
about that.
I was referring to the dma_pool allocations ... those don't need
to be atomic. OHCI or EHCI
On Wed, 16 May 2007 16:52:53 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
[...] Then you need to send specific
commands to the PCI-bridge, for example pshyco. From what I see
your model will not work in all cases.
USB through Psycho/Schizo is fully supported on Linux. Heck it works
On Tuesday 15 May 2007, Tzachi Perelstein wrote:
David Brownell wrote:
On Sunday 13 May 2007, Tzachi Perelstein wrote:
Hello,
I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has
a PCI/PCIE interfaces as well as an integrated USB controller.
While looking at
On Wed, 16 May 2007 11:38:47 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
I have never, ever, seen USB stack deplete the atomic pool completely
either, if this is what you are talking about. So, you're quite right
about that.
I was referring to the dma_pool allocations ... those
On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
It's worth pointing out that there already are drivers which
preallocate URBs and memory buffers and then share them among multiple
endpoints. One example is usb-storage.
This is for CBI transport, right? Honestly,
On Wednesday 16 May 2007, Alan Stern wrote:
On Wed, 16 May 2007, David Brownell wrote:
I have never, ever, seen USB stack deplete the atomic pool completely
either, if this is what you are talking about. So, you're quite right
about that.
I was referring to the dma_pool
Hello,
I seem to have problems with the ark3116 driver from 2.6.18.8. This is a
USB-RS232 cable. Just opening the /dev/ttyUSB0 device
gives (this is the
debug output enabled by `modprobe ark3116 debug=1`).
The lines that look suspicious are
/serial/ark3116.c: 124 1 bytes [0xFFB0]
and
On Wednesday 16 May 2007 18:00, David Brownell wrote:
On Wednesday 16 May 2007, Alan Stern wrote:
On Wed, 16 May 2007, David Brownell wrote:
I have never, ever, seen USB stack deplete the atomic pool completely
either, if this is what you are talking about. So, you're quite right
On Wed, 16 May 2007, Pete Zaitcev wrote:
On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
It's worth pointing out that there already are drivers which
preallocate URBs and memory buffers and then share them among multiple
endpoints. One example is
On Wed, 16 May 2007, Hans Petter Selasky wrote:
It is very clear to me that non-blocking memory allocation at the point of
starting an USB transfer will require extra error handling in the USB device
driver code!
It's not so clear to me.
My usbd_transfer_start() returns void. Your
On Wednesday 16 May 2007, Alan Stern wrote:
On Wed, 16 May 2007, Pete Zaitcev wrote:
Right. Per-endpoint with a size limits also allows TDs to be
preallocated.
With a large potential waste of memory!
Which is the general down-side of preallocation...
UHCI is so inefficient that
the
On Wednesday 16 May 2007 18:21, Alan Stern wrote:
On Wed, 16 May 2007, Pete Zaitcev wrote:
On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern
[EMAIL PROTECTED] wrote:
It's worth pointing out that there already are drivers which
preallocate URBs and memory buffers and then share them
On Wednesday 16 May 2007 18:25, Alan Stern wrote:
On Wed, 16 May 2007, Hans Petter Selasky wrote:
It is very clear to me that non-blocking memory allocation at the point
of starting an USB transfer will require extra error handling in the USB
device driver code!
It's not so clear to me.
On Wed, 16 May 2007, Hans Petter Selasky wrote:
It's also true for bulk-only; the same URB and buffer get used for the
IN and the OUT endpoints (CSW and CDB). Yes, we could dealias them if
necessary.
I would says it is a specification design fault that read and write endpoints
are not
On Wed, 16 May 2007, Hans Petter Selasky wrote:
On Wednesday 16 May 2007 18:25, Alan Stern wrote:
On Wed, 16 May 2007, Hans Petter Selasky wrote:
It is very clear to me that non-blocking memory allocation at the point
of starting an USB transfer will require extra error handling in the
Hi,
On Wednesday 16 May 2007 19:38, Alan Stern wrote:
On Wed, 16 May 2007, Hans Petter Selasky wrote:
On Wednesday 16 May 2007 18:25, Alan Stern wrote:
On Wed, 16 May 2007, Hans Petter Selasky wrote:
It is very clear to me that non-blocking memory allocation at the
point of starting
On Wed, 16 May 2007 18:11:35 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
My usbd_transfer_start() returns void. Your usb_submit_urb()
returns int.
We (ok, I) don't like this scheme. In Linux only SCSI uses it,
primarily because that's how Eric Youngdale defined it in 1992.
See, there
URB submission has other failure possibilities than lack of memory.
Those other things have to be checked for regardless.
Yes, but that is because you allow too many parameters in the URB to be
changed between USB transfers.
No; it's because unforeseen events can occur. For
On Wed, 16 May 2007 19:49:57 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
No; it's because unforeseen events can occur. For example, the device
may have been unplugged or suspended.
On FreeBSD it will never happen that you call the equivalent
of usb_submit_urb() after that the
Hi,
On Wednesday 16 May 2007 20:20, David Brownell wrote:
URB submission has other failure possibilities than lack of memory.
Those other things have to be checked for regardless.
Yes, but that is because you allow too many parameters in the URB to
be changed between USB
On Wednesday 16 May 2007 20:20, Pete Zaitcev wrote:
On Wed, 16 May 2007 18:11:35 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
My usbd_transfer_start() returns void. Your usb_submit_urb()
returns int.
We (ok, I) don't like this scheme. In Linux only SCSI uses it,
primarily because
Add support for Keyspan adapters: USA-49WG and USA-28XG
Signed-off-by: Lucy P. McCoy [EMAIL PROTECTED]
---
Sorry about the attachment but I can't get it to format correctly on my
email client.
keyspan_patch.2.6.21.gz
Description: application/gzip
Cc: Matthias Urlichs [EMAIL PROTECTED]
Cc: linux-usb-devel@lists.sourceforge.net
Signed-off-by: Ben Collins [EMAIL PROTECTED]
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 8c3f55b..89f067d 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
Cc: Ganesh Varadarajan [EMAIL PROTECTED]
Cc: linux-usb-devel@lists.sourceforge.net
Signed-off-by: Ben Collins [EMAIL PROTECTED]
diff --git a/drivers/usb/serial/ipaq.c b/drivers/usb/serial/ipaq.c
index 4df0ec7..7c85be4 100644
--- a/drivers/usb/serial/ipaq.c
+++ b/drivers/usb/serial/ipaq.c
@@
/* The first entry is a placeholder for the insmod-specified device */
-{ USB_DEVICE(0x049F, 0x0003) },
Is it obvious why this patch is correct? Especially given the
comment just before the line you delete, and the code
if (vendor) {
Ben Collins napsal(a):
Cc: Ganesh Varadarajan [EMAIL PROTECTED]
Cc: linux-usb-devel@lists.sourceforge.net
Signed-off-by: Ben Collins [EMAIL PROTECTED]
diff --git a/drivers/usb/serial/ipaq.c b/drivers/usb/serial/ipaq.c
index 4df0ec7..7c85be4 100644
--- a/drivers/usb/serial/ipaq.c
+++
On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
/* The first entry is a placeholder for the insmod-specified device */
- { USB_DEVICE(0x049F, 0x0003) },
Is it obvious why this patch is correct? Especially given the
comment just before the line you delete, and the code
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
On Wednesday 16 May 2007 20:20, David Brownell wrote:
URB submission has other failure possibilities than lack of memory.
Those other things have to be checked for regardless.
Yes, but that is because you allow too
76 matches
Mail list logo
