On Wed, Feb 21, 2007 at 10:24:02AM +0100, Robert Marquardt wrote:
Greg KH wrote:
Can you send this in 'diff -u' format so that I can apply it (or at
least determine where it should go in the driver?
Lets try it.
A diff of iowarrior.c and iowarrior.h from your kernel tree.
I renamed
Greg KH wrote:
I've made these changes, and the locking ones, and will send the driver
off to Linus in the next round of patches.
Please activate the the ioctl() calls. At least the GETINFO ioctl()
call. We can live without the others, but not without the GETINFO call.
--
Greg KH wrote:
Can you send this in 'diff -u' format so that I can apply it (or at
least determine where it should go in the driver?
Lets try it.
A diff of iowarrior.c and iowarrior.h from your kernel tree.
I renamed packet_size to report_size to make clear what is used in the
driver. The
Am 20.02.2007 um 19:04 schrieb Alan Stern:
On Tue, 20 Feb 2007, Guido Körber wrote:
OK, I am starting to understand where that comes from.
First of all USB does not allow to send two reports in a single
transfer.
That's right. Section 8.4 of the USB HID specification explicitly
says:
Am 20.02.2007 um 20:36 schrieb Alan Stern:
On Tue, 20 Feb 2007, Pete Zaitcev wrote:
On Tue, 20 Feb 2007 11:57:14 -0500 (EST), Alan Stern
[EMAIL PROTECTED] wrote:
On Tue, 20 Feb 2007, Guido Körber wrote:
There is no situation where a USB device sends multiple reports in
the same
On Wed, 21 Feb 2007, Guido Körber wrote:
But any device not following the specs will hit a wall with Windows
and MacOS as well.
Don't be so sure. In Pete's case, the misbehaving device was a Microsoft
keyboard! What makes you think Windows always implements the spec
exactly? (Hint -- it
On Wed, 21 Feb 2007, Guido Körber wrote:
Am 21.02.2007 um 16:31 schrieb Alan Stern:
On Wed, 21 Feb 2007, Guido Körber wrote:
But any device not following the specs will hit a wall with Windows
and MacOS as well.
Don't be so sure. In Pete's case, the misbehaving device was a
On Wed, 21 Feb 2007 12:05:55 -0500 (EST), Alan Stern [EMAIL PROTECTED] wrote:
The majority of keyboardS is low speed USB, they can send no more
than 8 bytes per transfer. The standard keyboard report is exactly 8
bytes long, so there is no chance of fitting two of them into the
same
I just found a bug in the IOWarrior hardware. It can report a wrong
wMaxPacketSize on interface 0. The diff fixes that in the driver.
781a782,784
if((dev-interface-cur_altsetting-desc.bInterfaceNumber == 0)
(dev-product_id == USB_DEVICE_ID_CODEMERCS_IOW56))
Robert Marquardt wrote:
I just found a bug in the IOWarrior hardware. It can report a wrong
wMaxPacketSize on interface 0. The diff fixes that in the driver.
To clarify. This is not a bug in the hardware. It is an inconsistency,
but it is valid. The problem is that the driver uses
On Tue, 20 Feb 2007, Robert Marquardt wrote:
Robert Marquardt wrote:
I just found a bug in the IOWarrior hardware. It can report a wrong
wMaxPacketSize on interface 0. The diff fixes that in the driver.
To clarify. This is not a bug in the hardware. It is an inconsistency,
but it is
PROTECTED], linux-usb-
[EMAIL PROTECTED], [EMAIL PROTECTED]
Betreff: Re: [linux-usb-devel] patch usb-iowarrior.patch added to
gregkh-2.6 tree
On Tue, 20 Feb 2007, Robert Marquardt wrote:
Robert Marquardt wrote:
I just found a bug in the IOWarrior hardware. It can report a wrong
On Tue, 20 Feb 2007, Guido Körber wrote:
Using maxPacketSize instead of ReportSize is never an option.
maxPacketSize signifies the maximum physical transfer size supported
by an individual endpoint. This value may be lower, equal, or higher
than ReportSize. In the last case multiple
Am 20.02.2007 um 17:17 schrieb Alan Stern:
On Tue, 20 Feb 2007, Guido Körber wrote:
Using maxPacketSize instead of ReportSize is never an option.
maxPacketSize signifies the maximum physical transfer size supported
by an individual endpoint. This value may be lower, equal, or higher
than
On Tue, 20 Feb 2007, Guido Körber wrote:
There is no situation where a USB device sends multiple reports in
the same packet.
I've never seen it happen myself, but Pete Zaitcev says he has:
http://marc.theaimsgroup.com/?l=linux-usb-develm=116545264427365w=2
Alan Stern
OK, I am starting to understand where that comes from.
First of all USB does not allow to send two reports in a single
transfer.
The effect that was described in the forum is likely something that
happens in the buffers of the host controller. Since he writes that
he had to ignore
On Tue, 20 Feb 2007, Guido Körber wrote:
OK, I am starting to understand where that comes from.
First of all USB does not allow to send two reports in a single
transfer.
That's right. Section 8.4 of the USB HID specification explicitly says:
Only one report is allowed in a
On Tue, 20 Feb 2007 11:57:14 -0500 (EST), Alan Stern [EMAIL PROTECTED] wrote:
On Tue, 20 Feb 2007, Guido Körber wrote:
There is no situation where a USB device sends multiple reports in
the same packet.
I've never seen it happen myself, but Pete Zaitcev says he has:
On Tue, 20 Feb 2007 14:36:33 -0500 (EST), Alan Stern [EMAIL PROTECTED] wrote:
Here's the argument for using the maxpacket size:
I am not completely persuaded... But at least I see what you're thinking,
thanks for the explanation.
What are we going to do about iowarror specifically? It would
On Tue, 20 Feb 2007, Pete Zaitcev wrote:
What are we going to do about iowarror specifically? It would not be the
first time we work around broken descriptors.
Until/unless other examples show up, I'd say to use the patch written by
Robert Marquardt (provided he submits it in the proper
On Tue, Feb 20, 2007 at 03:48:03PM +0100, Robert Marquardt wrote:
I just found a bug in the IOWarrior hardware. It can report a wrong
wMaxPacketSize on interface 0. The diff fixes that in the driver.
781a782,784
if((dev-interface-cur_altsetting-desc.bInterfaceNumber == 0)
Alan Stern wrote:
It depends what you want to use it for. For some purposes it is better to
use the maxpacket value instead of the report size.
Alan Stern
In this case definitely the report size is needed. I will change the
variable name to reflect that. As soon as i know where to get
On Thu, Feb 15, 2007 at 11:00:35AM -0500, Alex Villac??s Lasso wrote:
The usb-iowarrior patch looks interesting, since it might be used to
drive a particular USB-IrDA dongle I have (idProduct 0x4200). I have a
strong suspicion that this dongle is nothing more than a serial device
wired to a
Oliver Neukum wrote:
Am Donnerstag, 15. Februar 2007 19:35 schrieb Greg KH:
On Thu, Feb 15, 2007 at 01:51:31PM +0100, Oliver Neukum wrote:
Am Donnerstag, 15. Februar 2007 00:31 schrieb [EMAIL PROTECTED]:
+??dev = (struct iowarrior *)file-private_data;
+
+??/* verify
Samuel Ortiz wrote:
Oliver Neukum wrote:
Am Donnerstag, 15. Februar 2007 19:35 schrieb Greg KH:
On Thu, Feb 15, 2007 at 01:51:31PM +0100, Oliver Neukum wrote:
Am Donnerstag, 15. Februar 2007 00:31 schrieb [EMAIL PROTECTED]:
+??dev = (struct iowarrior *)file-private_data;
+
Am Freitag, 16. Februar 2007 09:41 schrieb Samuel Ortiz:
One stupid question: Suppose we're in iowarrior_read(), got a pointer on
private_data, but haven't taken the mutex yet. iowarrior_release() is
called, locks the mutex, decrements the opened counter to 0, and then
call
Oliver Neukum wrote:
Am Freitag, 16. Februar 2007 09:41 schrieb Samuel Ortiz:
One stupid question: Suppose we're in iowarrior_read(), got a pointer on
private_data, but haven't taken the mutex yet. iowarrior_release() is
called, locks the mutex, decrements the opened counter to 0, and then
Am Freitag, 16. Februar 2007 12:40 schrieb Samuel Ortiz:
Oliver Neukum wrote:
Am Freitag, 16. Februar 2007 09:41 schrieb Samuel Ortiz:
One stupid question: Suppose we're in iowarrior_read(), got a pointer on
private_data, but haven't taken the mutex yet. iowarrior_release() is
Am Donnerstag, 15. Februar 2007 00:31 schrieb [EMAIL PROTECTED]:
+ dev = (struct iowarrior *)file-private_data;
+
+ /* verify that the device wasn't unplugged */
+ if (dev == NULL || !dev-present) {
+ retval = -ENODEV;
+ goto exit;
+ }
Oliver Neukum wrote:
This needs the lock to be taken. You've a race condition that allows
URBs to be submitted for an interface that somebody else may have
claimed.
Regards
Oliver
Thanks for the info. I think Greg should fix that in his version to
avoid any problems
Am Donnerstag, 15. Februar 2007 14:27 schrieb Robert Marquardt:
Oliver Neukum wrote:
This needs the lock to be taken. You've a race condition that allows
URBs to be submitted for an interface that somebody else may have
claimed.
Regards
Oliver
Thanks for the
[EMAIL PROTECTED] wrote:
+static int iowarrior_release(struct inode *inode, struct file *file)
+{
+ struct iowarrior *dev;
+ int retval = 0;
+
+ dev = (struct iowarrior *)file-private_data;
+ if (dev == NULL) {
+ return -ENODEV;
+ }
+
+ dbg(%s -
Samuel Ortiz wrote:
[EMAIL PROTECTED] wrote:
+static int iowarrior_release(struct inode *inode, struct file *file)
+{
+struct iowarrior *dev;
+int retval = 0;
+
+dev = (struct iowarrior *)file-private_data;
+if (dev == NULL) {
+return -ENODEV;
+}
+
+
On Thu, Feb 15, 2007 at 02:38:08PM +0100, Oliver Neukum wrote:
Am Donnerstag, 15. Februar 2007 14:27 schrieb Robert Marquardt:
Oliver Neukum wrote:
This needs the lock to be taken. You've a race condition that allows
URBs to be submitted for an interface that somebody else may have
The usb-iowarrior patch looks interesting, since it might be used to
drive a particular USB-IrDA dongle I have (idProduct 0x4200). I have a
strong suspicion that this dongle is nothing more than a serial device
wired to a IR transceiver. What should I take into account in order to
test this
On Thu, Feb 15, 2007 at 03:56:54PM +0100, Robert Marquardt wrote:
Samuel Ortiz wrote:
[EMAIL PROTECTED] wrote:
+static int iowarrior_release(struct inode *inode, struct file *file)
+{
+struct iowarrior *dev;
+int retval = 0;
+
+dev = (struct iowarrior *)file-private_data;
+
On Thu, Feb 15, 2007 at 03:18:23PM +0100, Samuel Ortiz wrote:
[EMAIL PROTECTED] wrote:
+static int iowarrior_release(struct inode *inode, struct file *file)
+{
+struct iowarrior *dev;
+int retval = 0;
+
+dev = (struct iowarrior *)file-private_data;
+if (dev == NULL) {
+
On Thu, Feb 15, 2007 at 01:51:31PM +0100, Oliver Neukum wrote:
Am Donnerstag, 15. Februar 2007 00:31 schrieb [EMAIL PROTECTED]:
+??dev = (struct iowarrior *)file-private_data;
+
+??/* verify that the device wasn't unplugged */
+??if (dev == NULL ||
Am Donnerstag, 15. Februar 2007 19:35 schrieb Greg KH:
On Thu, Feb 15, 2007 at 01:51:31PM +0100, Oliver Neukum wrote:
Am Donnerstag, 15. Februar 2007 00:31 schrieb [EMAIL PROTECTED]:
+??dev = (struct iowarrior *)file-private_data;
+
+??/* verify that the device
This is a note to let you know that I've just added the patch titled
Subject: USB: add driver for iowarrior devices.
to my gregkh-2.6 tree. Its filename is
usb-iowarrior.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
40 matches
Mail list logo
