Hi,
the kobil_sct didn't work with uhci hcds.
It used usb_fill_bulk_urb instead of usb_fill_int_urb.
The attached patch fixes this.
It starts reading in open now - this gives apps (CT-API) the chance to
detect the p'n'p string correctly.
Greg, please apply.
Best regards
hanks in advance
Thomas Wahrenbruch
May 14 16:44:09 linux kernel: drivers/usb/serial/usb-serial.c: USB Serial support
registered for KOBIL USB smart card terminal
May 14 16:44:09 linux kernel: drivers/usb/core/usb.c: registered new driver kobil
May 14 16:44:09 linux kernel: drivers/usb/s
Hi,
as promised - here is the patch for 2.5.70:
Added support for KAAN SIM in kobil_sct.
Greg, please apply.
Best regards
Thomas
--
-
Thomas Wahrenbruch
Hardware Development
KOBIL Systems GmbH
Pfortenring 11 D-67547 Worms
- linux-2.4.18/drivers/usb/serial/kobil_sct.c Thu Jan 1 01:00:00 1970
+++ linux-2.4.18-thomas/drivers/usb/serial/kobil_sct.c Mon Nov 11 15:32:05 2002
@@ -0,0 +1,722 @@
+/*
+ * KOBIL USB Smart Card Terminal Driver
+ *
+ * Copyright (C) 2002 KOBIL Systems GmbH
+ * Author: Thomas Wahrenbruch
+ *
+ * Co
Jan 1 01:00:00 1970
+++ linux-2.4.18-thomas/drivers/usb/serial/kobil_sct.c Thu Nov 7 15:43:21 2002
@@ -0,0 +1,722 @@
+/*
+ * KOBIL USB Smart Card Terminal Driver
+ *
+ * Copyright (C) 2002 KOBIL Systems GmbH
+ * Author: Thomas Wahrenbruch
+ *
+ * Contact: [EMAIL PROTECTED]
+ *
+ * This p
mpletion" bugs got fixed in all 2.4 HCDs,
but I'd still encourage you to test carefully.
- Dave
Thanks for your time.
Thomas Wahrenbruch
---
This sf.net email is sponsored by:ThinkGeek
We
delay() until 16ms are over?
(and I think that our customers don't like to use a 2.5.xx kernel...)
Give that a try when it comes out.
- Dave
Regards,
Thomas Wahrenbruch
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek he
) does 16ms busy-waiting. I tried to call schedule_timeout(),
but this function is not precise enough.
Is there an alternative for mdelay(16)?
How does the usb-core achieve that the interrupt-in endpoint is polled
exactly every X ms (X=8, with our device)?
Best regards,
Thomas Wahrenbruch
>>Hi all,
>>
>>in my driver for our usb-serial converter I want to pass the received data
>>back.
>>But after every
>>tty_insert_flip_char(tty, data[i], 0);
>>call, my write method is called with data[i] or something else (0x5E, 0x40,
>>0x41 mostly).
>>
>>What could be the reason for this?
>>Who
Hi all,
in my driver for our usb-serial converter I want to pass the received data back.
But after every
tty_insert_flip_char(tty, data[i], 0);
call, my write method is called with data[i] or something else (0x5E, 0x40, 0x41
mostly).
What could be the reason for this?
Who calls my write method?
#include "SerialUSBConverterRequests.h"
#include "usb-debug.c"
#ifdef CONFIG_USB_SERIAL_DEBUG
static int debug = 1;
#else
static int debug;
#endif
#include "usb-serial.h"
/*
* Version Information
*/
#define DRIVER_VERSION "v0.01"
#define DRIVER_AUTHOR "
Hi all,
when I attach our USB-Serial Converter I get a kernel oops.
Is it possible that a module has problems to evaluate the device
descriptor? (One interface with three alternate settings)
Best regards
Thomas Wahrenbruch
[root@darkred root]# cat /proc/bus/usb/devices
T: Bus=02
gs.
Kernel 2.4.18-3 (Red hat 7.3)
Kind regards
Thomas Wahrenbruch
static void my_complete( struct urb *purb )
{
char* p_dummy;
int i;
struct usb_serial_port *port;
p_dummy = purb->transfer_buffer;
printk(KERN_DEBUG "Transfer Buffer: ");
for (i = 0; i
13 matches
Mail list logo