On Thu, 24 Mar 2005 16:37:21 +0100 Paul Koster <[EMAIL PROTECTED]> wrote:
> When I disable the iso URB submitting, the bulk works well for
> about 2 minutes. Unloading the
> driver results most of the time in kernel panics, but only when I actively
> used the driver in a open/close session.
I don't know much about ISO, but the above was mildly interesting.
But I gave up reading pretty quickly. Took me 30 seconds to reach
this part:
> static ssize_t fusbi_read(struct file *file, char *buffer, size_t count,
> loff_t *ppos)
> {
> char* temp_buffer = NULL;
>
> // Allocate temporary buffer
> temp_buffer = kmalloc(count, GFP_KERNEL);
>
> // Read from user buffer
> true_count = fusbi_dequeue_buffer(dev, temp_buffer, count);
> }
Dude, you do realize that anything above 8K has NO chance to work?
The kmalloc will always fail (unchecked).
This is hideous, too:
case -EOVERFLOW: {
// This error occurs when a read request reads less bytes than
the buffer
contains.
// We use this option to determine the protocol packetlength
(byte 3) and
read the whole packet.
if(dev->bulk_recv_buffer[0] == 0xAA && dev->bulk_recv_buffer[1]
== 0xAA)
read_size = dev->bulk_recv_buffer[2] * 2 + 6;
else
read_size = 3;
break;
}
Hardware designers strike! The length is 518 bytes at most (+3 bytes
header). Would it be too hard to read that much always, and therminate
the URB with short read?
I think it's duff hardware. But the driver not being too pretty is not
helping things either.
-- Pete
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
