Re: [linux-usb-devel] [PATCH] iuu_phoenix - new release v0.4 - call for review/comments
+static int iuu_alloc_buf(struct iuu_private *priv)
+{
+ priv-buf = kzalloc(256, GFP_KERNEL);
+ priv-dbgbuf = kzalloc(256, GFP_KERNEL);
+ priv-writebuf = kzalloc(256, GFP_KERNEL);
+ if (!priv-buf || !priv-dbgbuf || !priv-writebuf) {
+ dbg(%s problem allocation buffer, __FUNCTION__);
+ return -ENOMEM;
+ }
+ return 0;
+}
Given they have the same lifetime what is wrong with simply putting them
in struct iuu_private as arrays ?
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iuu_phoenix - new release v0.4 - call for review/comments
+static int
+iuu_ioctl(struct usb_serial_port *port, struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+
This is very wrong. Your driver may not intercept TCGETS and similar
ioctls. In fact you don't seem to need any of it. Terminal changes are
handled by the set_termios callback you provide. I'd just delete the
ioctl method for now (note a lot of other usb serial drivers get it wrong
and I'm busy cleaning them all up)
+ if (tty urb-actual_length data != NULL ) {
+ tty_buffer_request_room(tty, urb-actual_length + 1);
+ for (i = 0; i urb-actual_length; ++i)
+ tty_insert_flip_char(tty, data[i], TTY_NORMAL);
We've got tty_insert_flip_string for this case which is a bit simpler.
You can just do
if (tty) {
tty_insert_flip_string(tty, data, urb-actual_length);
tty_flip_buffer_push(tty);
}
+static int
+iuu_uart_baud(struct usb_serial_port *port, u_int32_t baud, u_int32_t
*actual,
+ u_int8_t parity)
u32 not u_int32_t by preference (or in fact we have speed_t for speeds)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iuu_phoenix - new release v0.4 - call for review/comments
On Mon, 13 Aug 2007 15:48:40 +0200
Oliver Neukum [EMAIL PROTECTED] wrote:
Am Montag 13 August 2007 schrieb Alan Cox:
+static int iuu_alloc_buf(struct iuu_private *priv)
+{
+ priv-buf = kzalloc(256, GFP_KERNEL);
+ priv-dbgbuf = kzalloc(256, GFP_KERNEL);
+ priv-writebuf = kzalloc(256, GFP_KERNEL);
+ if (!priv-buf || !priv-dbgbuf || !priv-writebuf) {
+ dbg(%s problem allocation buffer, __FUNCTION__);
+ return -ENOMEM;
+ }
+ return 0;
+}
Given they have the same lifetime what is wrong with simply putting them
in struct iuu_private as arrays ?
Alignment issue for the architectures which don't have cache consistent DMA.
Is using __cacheline_aligned not sufficient for that ?
Alan
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Support for the Evolution Scorpion robots
I'm sorry if I don't provide everything you usually require, but as I said, I'm not really a kernel guy :-) New ids look fine. NAK the speed hack however. The kernel now has arbitary speed support so this is the wrong way to approach it. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Support for the Evolution Scorpion robots
Okay. Like I said, I'm not really a kernel guy, and atm I really don't feel like being one :-) N/P - the extra identifiers are fine. I could probably figure out how to do the speed hack in the right way, but it would require a lot of work for me (I've never even seen any of the kernel code before). Could I persuade somebody on this list to implement the speed setting correct? I know I'm asking busy people to do my work, but I'm not really the best man for the job. With a current kernel you shouldn't need one you can simply do struct termios2 t2; ioctl(ttyfd, TCGETS2, t2); t2.c_cflags = ~CBAUD; t2.c_cflags |= BOTHER; t2.c_ospeed = 25; ioctl(ttyfd, TCSETS2, t2) and at some point once its all synced up for the various platforms glibc will handle the newer termios transparently as it already has ispeed/ospeed information in the version it presents user applications. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Support for the Evolution Scorpion robots
I'm sorry about all the noise, but what you just said made no sense to me at all (I told you I wasn't a kernel guy ;-) ). If I understand correctly all that is needed is the device ID's for the robots to be supported? So no need to implement the speed hack in the kernel at all? For the latest kernels correct - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] kl5kusb105: Switch to new speed API
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/kl5kusb105.c
linux-2.6.23rc1-mm1/drivers/usb/serial/kl5kusb105.c
--- linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/kl5kusb105.c 2007-07-26
15:01:52.0 +0100
+++ linux-2.6.23rc1-mm1/drivers/usb/serial/kl5kusb105.c 2007-07-26
15:31:04.0 +0100
@@ -728,24 +728,24 @@
#endif
}
- switch(cflag CBAUD) {
- case B0: /* handled below */
+ switch(tty_get_baud_rate(port-tty)) {
+ case 0: /* handled below */
break;
- case B1200: priv-cfg.baudrate = kl5kusb105a_sio_b1200;
+ case 1200: priv-cfg.baudrate = kl5kusb105a_sio_b1200;
break;
- case B2400: priv-cfg.baudrate = kl5kusb105a_sio_b2400;
+ case 2400: priv-cfg.baudrate = kl5kusb105a_sio_b2400;
break;
- case B4800: priv-cfg.baudrate = kl5kusb105a_sio_b4800;
+ case 4800: priv-cfg.baudrate = kl5kusb105a_sio_b4800;
break;
- case B9600: priv-cfg.baudrate = kl5kusb105a_sio_b9600;
+ case 9600: priv-cfg.baudrate = kl5kusb105a_sio_b9600;
break;
- case B19200: priv-cfg.baudrate = kl5kusb105a_sio_b19200;
+ case 19200: priv-cfg.baudrate = kl5kusb105a_sio_b19200;
break;
- case B38400: priv-cfg.baudrate = kl5kusb105a_sio_b38400;
+ case 38400: priv-cfg.baudrate = kl5kusb105a_sio_b38400;
break;
- case B57600: priv-cfg.baudrate = kl5kusb105a_sio_b57600;
+ case 57600: priv-cfg.baudrate = kl5kusb105a_sio_b57600;
break;
- case B115200: priv-cfg.baudrate = kl5kusb105a_sio_b115200;
+ case 115200: priv-cfg.baudrate = kl5kusb105a_sio_b115200;
break;
default:
err(KLSI USB-Serial converter:
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] cp2101: Remove broken termios optimisation, use proper speed API
I've also enabled the commented out support for 7200, 14400, 55854,
127117 and 3686400 baud as you can now set such rates in the kernel.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/cp2101.c
linux-2.6.23rc1-mm1/drivers/usb/serial/cp2101.c
--- linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/cp2101.c 2007-07-26
15:01:51.0 +0100
+++ linux-2.6.23rc1-mm1/drivers/usb/serial/cp2101.c 2007-07-26
15:30:20.0 +0100
@@ -356,7 +356,7 @@
dbg(%s - port %d, __FUNCTION__, port-number);
- if ((!port-tty) || (!port-tty-termios)) {
+ if (!port-tty || !port-tty-termios) {
dbg(%s - no tty structures, __FUNCTION__);
return;
}
@@ -526,50 +526,35 @@
return;
}
cflag = port-tty-termios-c_cflag;
-
- /* Check that they really want us to change something */
- if (old_termios) {
- if ((cflag == old_termios-c_cflag)
- (RELEVANT_IFLAG(port-tty-termios-c_iflag)
- == RELEVANT_IFLAG(old_termios-c_iflag))) {
- dbg(%s - nothing to change..., __FUNCTION__);
- return;
- }
-
- old_cflag = old_termios-c_cflag;
- }
-
+ old_cflag = old_termios-c_cflag;
+ baud = tty_get_baud_rate(port-tty);
+
/* If the baud rate is to be updated*/
- if ((cflag CBAUD) != (old_cflag CBAUD)) {
- switch (cflag CBAUD) {
- /*
-* The baud rates which are commented out below
-* appear to be supported by the device
-* but are non-standard
-*/
- case B0:baud = 0; break;
- case B600: baud = 600; break;
- case B1200: baud = 1200;break;
- case B1800: baud = 1800;break;
- case B2400: baud = 2400;break;
- case B4800: baud = 4800;break;
- /*case B7200: baud = 7200;break;*/
- case B9600: baud = 9600;break;
- /*ase B14400: baud = 14400; break;*/
- case B19200:baud = 19200; break;
- /*case B28800: baud = 28800; break;*/
- case B38400:baud = 38400; break;
- /*case B55854: baud = 55054; break;*/
- case B57600:baud = 57600; break;
- case B115200: baud = 115200; break;
- /*case B127117: baud = 127117; break;*/
- case B230400: baud = 230400; break;
- case B460800: baud = 460800; break;
- case B921600: baud = 921600; break;
- /*case B3686400:baud = 3686400; break;*/
+ if (baud != tty_termios_baud_rate(old_termios)) {
+ switch (baud) {
+ case 0:
+ case 600:
+ case 1200:
+ case 1800:
+ case 2400:
+ case 4800:
+ case 7200:
+ case 9600:
+ case 14400:
+ case 19200:
+ case 28800:
+ case 38400:
+ case 55854:
+ case 57600:
+ case 115200:
+ case 127117:
+ case 230400:
+ case 460800:
+ case 921600:
+ case 3686400:
+ break;
default:
- dev_err(port-dev, cp2101 driver does not
- support the baudrate requested\n);
+ baud = 9600;
break;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] mct_u232: Convert to proper speed handling API
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/mct_u232.c
linux-2.6.23rc1-mm1/drivers/usb/serial/mct_u232.c
--- linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/mct_u232.c 2007-07-26
15:01:52.0 +0100
+++ linux-2.6.23rc1-mm1/drivers/usb/serial/mct_u232.c 2007-07-26
15:31:17.0 +0100
@@ -184,21 +184,21 @@
* we do not know how to support. We ignore them for the moment.
* XXX Rate-limit the error message, it's user triggerable.
*/
-static int mct_u232_calculate_baud_rate(struct usb_serial *serial, int value)
+static int mct_u232_calculate_baud_rate(struct usb_serial *serial, speed_t
value)
{
if (le16_to_cpu(serial-dev-descriptor.idProduct) ==
MCT_U232_SITECOM_PID
|| le16_to_cpu(serial-dev-descriptor.idProduct) ==
MCT_U232_BELKIN_F5U109_PID) {
switch (value) {
- caseB300: return 0x01;
- caseB600: return 0x02; /* this one not tested */
- case B1200: return 0x03;
- case B2400: return 0x04;
- case B4800: return 0x06;
- case B9600: return 0x08;
- case B19200: return 0x09;
- case B38400: return 0x0a;
- case B57600: return 0x0b;
- case B115200: return 0x0c;
+ case300: return 0x01;
+ case600: return 0x02; /* this one not tested */
+ case 1200: return 0x03;
+ case 2400: return 0x04;
+ case 4800: return 0x06;
+ case 9600: return 0x08;
+ case 19200: return 0x09;
+ case 38400: return 0x0a;
+ case 57600: return 0x0b;
+ case 115200: return 0x0c;
default:
err(MCT USB-RS232: unsupported baudrate request 0x%x,
using default of B9600, value);
@@ -206,27 +206,27 @@
}
} else {
switch (value) {
- caseB300: value = 300; break;
- caseB600: value = 600; break;
- case B1200: value =1200; break;
- case B2400: value =2400; break;
- case B4800: value =4800; break;
- case B9600: value =9600; break;
- case B19200: value = 19200; break;
- case B38400: value = 38400; break;
- case B57600: value = 57600; break;
- case B115200: value = 115200; break;
- default:
- err(MCT USB-RS232: unsupported baudrate request 0x%x,
-using default of B9600, value);
- value = 9600;
+ case 300: break;
+ case 600: break;
+ case 1200: break;
+ case 2400: break;
+ case 4800: break;
+ case 9600: break;
+ case 19200: break;
+ case 38400: break;
+ case 57600: break;
+ case 115200: break;
+ default:
+ err(MCT USB-RS232: unsupported baudrate
request 0x%x,
+using default of B9600, value);
+ value = 9600;
}
return 115200/value;
}
}
static int mct_u232_set_baud_rate(struct usb_serial *serial, struct
usb_serial_port *port,
- int value)
+ speed_t value)
{
__le32 divisor;
int rc;
@@ -634,7 +634,7 @@
mct_u232_set_modem_ctrl(serial, control_state);
}
- mct_u232_set_baud_rate(serial, port, cflag CBAUD);
+ mct_u232_set_baud_rate(serial, port, tty_get_baud_rate(port-tty));
if ((cflag CBAUD) == B0 ) {
dbg(%s: baud is B0, __FUNCTION__);
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/mct_u232.h
linux-2.6.23rc1-mm1/drivers/usb/serial/mct_u232.h
--- linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/mct_u232.h 2007-07-26
15:01:52.0 +0100
+++ linux-2.6.23rc1-mm1/drivers/usb/serial/mct_u232.h 2007-07-26
15:31:24.0 +0100
@@ -79,7 +79,7 @@
* and Intel solution. They are the regular MCT and Sitecom for us.
* This is pointless to document in the header, see the code for the bits.
*/
-static int mct_u232_calculate_baud_rate(struct usb_serial *serial, int value);
+static int mct_u232_calculate_baud_rate(struct usb_serial *serial, speed_t
value);
/*
* Line Control Register (LCR)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through
[linux-usb-devel] [PATCH] digi_acceleport: Drag the driver kicking and screaming into coding style
- The outbreak of acute bracketitus has been cured
- The belief that brackets should have spaces everywhere likewise
- Various other coding style tweaks
- Use baud rates not Bfoo in the speed setup switch
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/digi_acceleport.c
linux-2.6.23rc1-mm1/drivers/usb/serial/digi_acceleport.c
--- linux.vanilla-2.6.23rc1-mm1/drivers/usb/serial/digi_acceleport.c
2007-07-26 15:01:52.0 +0100
+++ linux-2.6.23rc1-mm1/drivers/usb/serial/digi_acceleport.c2007-07-26
15:30:36.0 +0100
@@ -433,38 +433,38 @@
/* Local Function Declarations */
-static void digi_wakeup_write( struct usb_serial_port *port );
+static void digi_wakeup_write(struct usb_serial_port *port);
static void digi_wakeup_write_lock(struct work_struct *work);
-static int digi_write_oob_command( struct usb_serial_port *port,
- unsigned char *buf, int count, int interruptible );
-static int digi_write_inb_command( struct usb_serial_port *port,
- unsigned char *buf, int count, unsigned long timeout );
-static int digi_set_modem_signals( struct usb_serial_port *port,
- unsigned int modem_signals, int interruptible );
-static int digi_transmit_idle( struct usb_serial_port *port,
- unsigned long timeout );
+static int digi_write_oob_command(struct usb_serial_port *port,
+ unsigned char *buf, int count, int interruptible);
+static int digi_write_inb_command(struct usb_serial_port *port,
+ unsigned char *buf, int count, unsigned long timeout);
+static int digi_set_modem_signals(struct usb_serial_port *port,
+ unsigned int modem_signals, int interruptible);
+static int digi_transmit_idle(struct usb_serial_port *port,
+ unsigned long timeout);
static void digi_rx_throttle (struct usb_serial_port *port);
static void digi_rx_unthrottle (struct usb_serial_port *port);
-static void digi_set_termios( struct usb_serial_port *port,
- struct ktermios *old_termios );
-static void digi_break_ctl( struct usb_serial_port *port, int break_state );
-static int digi_ioctl( struct usb_serial_port *port, struct file *file,
- unsigned int cmd, unsigned long arg );
-static int digi_tiocmget( struct usb_serial_port *port, struct file *file );
-static int digi_tiocmset( struct usb_serial_port *port, struct file *file,
- unsigned int set, unsigned int clear );
-static int digi_write( struct usb_serial_port *port, const unsigned char *buf,
int count );
-static void digi_write_bulk_callback( struct urb *urb );
-static int digi_write_room( struct usb_serial_port *port );
-static int digi_chars_in_buffer( struct usb_serial_port *port );
-static int digi_open( struct usb_serial_port *port, struct file *filp );
-static void digi_close( struct usb_serial_port *port, struct file *filp );
-static int digi_startup_device( struct usb_serial *serial );
-static int digi_startup( struct usb_serial *serial );
-static void digi_shutdown( struct usb_serial *serial );
-static void digi_read_bulk_callback( struct urb *urb );
-static int digi_read_inb_callback( struct urb *urb );
-static int digi_read_oob_callback( struct urb *urb );
+static void digi_set_termios(struct usb_serial_port *port,
+ struct ktermios *old_termios);
+static void digi_break_ctl(struct usb_serial_port *port, int break_state);
+static int digi_ioctl(struct usb_serial_port *port, struct file *file,
+ unsigned int cmd, unsigned long arg);
+static int digi_tiocmget(struct usb_serial_port *port, struct file *file);
+static int digi_tiocmset(struct usb_serial_port *port, struct file *file,
+ unsigned int set, unsigned int clear);
+static int digi_write(struct usb_serial_port *port, const unsigned char *buf,
int count);
+static void digi_write_bulk_callback(struct urb *urb);
+static int digi_write_room(struct usb_serial_port *port);
+static int digi_chars_in_buffer(struct usb_serial_port *port);
+static int digi_open(struct usb_serial_port *port, struct file *filp);
+static void digi_close(struct usb_serial_port *port, struct file *filp);
+static int digi_startup_device(struct usb_serial *serial);
+static int digi_startup(struct usb_serial *serial);
+static void digi_shutdown(struct usb_serial *serial);
+static void digi_read_bulk_callback(struct urb *urb);
+static int digi_read_inb_callback(struct urb *urb);
+static int digi_read_oob_callback(struct urb *urb);
/* Statics */
@@ -576,9 +576,9 @@
* with the equivalent code.
*/
-static inline long cond_wait_interruptible_timeout_irqrestore(
+static long cond_wait_interruptible_timeout_irqrestore(
wait_queue_head_t *q, long timeout,
- spinlock_t *lock, unsigned long flags )
+ spinlock_t *lock, unsigned long flags)
{
DEFINE_WAIT(wait);
@@ -600,18 +600,16 @@
static void digi_wakeup_write_lock(struct work_struct *work)
{
- struct digi_port *priv =
- container_of(work
Re: [linux-usb-devel] [PATCH] [IrDA] KS959 USB IrDA dongle support
Too late, Linus just closed the merge window, you had two weeks to submit this :-) Too bad... I submitted it as soon as it was ready. Will we have to wait until the 2.6.24 merge window, or can it be applied earlier as it's a fully standalone driver ? You can always send Linus a copy and ask but if its just finished then far better to send it to Andrew so that it can get testing and picked at in -mm then merged next time around when polished. Alan - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] mos7840.c: Turn this into a serial driver
The MOS driver is interesting, in a bad kind of 'how the hell did this
get merged' kind of way
- Remove the bogus termios change check
- Remove the duplicate code for half the ioctls
- Remove the supporting code to duplicate the ioctl code
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/mos7840.c
linux-2.6.22-rc6-mm1/drivers/usb/serial/mos7840.c
--- linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/mos7840.c 2007-07-02
20:50:14.0 +0100
+++ linux-2.6.22-rc6-mm1/drivers/usb/serial/mos7840.c 2007-07-02
21:25:13.0 +0100
@@ -2189,16 +2189,6 @@
return;
}
- /* check that they really want us to change something */
- if (old_termios) {
- if ((cflag == old_termios-c_cflag)
- (RELEVANT_IFLAG(tty-termios-c_iflag) ==
-RELEVANT_IFLAG(old_termios-c_iflag))) {
- dbg(%s\n, Nothing to change);
- return;
- }
- }
-
dbg(%s - clfag %08x iflag %08x, __FUNCTION__,
tty-termios-c_cflag, RELEVANT_IFLAG(tty-termios-c_iflag));
@@ -2258,30 +2248,6 @@
}
/*
- * mos7840_get_bytes_avail - get number of bytes available
- *
- * Purpose: Let user call ioctl to get the count of number of bytes available.
- */
-
-static int mos7840_get_bytes_avail(struct moschip_port *mos7840_port,
- unsigned int __user *value)
-{
- unsigned int result = 0;
- struct tty_struct *tty = mos7840_port-port-tty;
-
- if (!tty)
- return -ENOIOCTLCMD;
-
- result = tty-read_cnt;
-
- dbg(%s(%d) = %d, __FUNCTION__, mos7840_port-port-number, result);
- if (copy_to_user(value, result, sizeof(int)))
- return -EFAULT;
-
- return -ENOIOCTLCMD;
-}
-
-/*
* mos7840_set_modem_info
* function to set modem info
*/
@@ -2429,8 +2395,6 @@
struct async_icount cprev;
struct serial_icounter_struct icount;
int mosret = 0;
- int retval;
- struct tty_ldisc *ld;
if (mos7840_port_paranoia_check(port, __FUNCTION__)) {
dbg(%s, Invalid port \n);
@@ -2449,42 +2413,6 @@
switch (cmd) {
/* return number of bytes available */
- case TIOCINQ:
- dbg(%s (%d) TIOCINQ, __FUNCTION__, port-number);
- return mos7840_get_bytes_avail(mos7840_port, argp);
-
- case TIOCOUTQ:
- dbg(%s (%d) TIOCOUTQ, __FUNCTION__, port-number);
- return put_user(tty-driver-chars_in_buffer ?
- tty-driver-chars_in_buffer(tty) : 0,
- (int __user *)arg);
-
- case TCFLSH:
- retval = tty_check_change(tty);
- if (retval)
- return retval;
-
- ld = tty_ldisc_ref(tty);
- switch (arg) {
- case TCIFLUSH:
- if (ld ld-flush_buffer)
- ld-flush_buffer(tty);
- break;
- case TCIOFLUSH:
- if (ld ld-flush_buffer)
- ld-flush_buffer(tty);
- /* fall through */
- case TCOFLUSH:
- if (tty-driver-flush_buffer)
- tty-driver-flush_buffer(tty);
- break;
- default:
- tty_ldisc_deref(ld);
- return -EINVAL;
- }
- tty_ldisc_deref(ld);
- return 0;
-
case TIOCSERGETLSR:
dbg(%s (%d) TIOCSERGETLSR, __FUNCTION__, port-number);
return mos7840_get_lsr_info(mos7840_port, argp);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] pl2303: remove bogus checks and fix speed support to use tty_get_baud_rate()
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/pl2303.c
linux-2.6.22-rc6-mm1/drivers/usb/serial/pl2303.c
--- linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/pl2303.c2007-07-02
20:50:14.0 +0100
+++ linux-2.6.22-rc6-mm1/drivers/usb/serial/pl2303.c2007-07-02
21:25:13.0 +0100
@@ -484,15 +484,6 @@
spin_unlock_irqrestore(priv-lock, flags);
cflag = port-tty-termios-c_cflag;
- /* check that they really want us to change something */
- if (old_termios) {
- if ((cflag == old_termios-c_cflag)
- (RELEVANT_IFLAG(port-tty-termios-c_iflag) ==
-RELEVANT_IFLAG(old_termios-c_iflag))) {
- dbg(%s - nothing to change..., __FUNCTION__);
- return;
- }
- }
buf = kzalloc(7, GFP_KERNEL);
if (!buf) {
@@ -517,29 +508,7 @@
dbg(%s - data bits = %d, __FUNCTION__, buf[6]);
}
- baud = 0;
- switch (cflag CBAUD) {
- case B0:baud = 0; break;
- case B75: baud = 75; break;
- case B150: baud = 150; break;
- case B300: baud = 300; break;
- case B600: baud = 600; break;
- case B1200: baud = 1200;break;
- case B1800: baud = 1800;break;
- case B2400: baud = 2400;break;
- case B4800: baud = 4800;break;
- case B9600: baud = 9600;break;
- case B19200:baud = 19200; break;
- case B38400:baud = 38400; break;
- case B57600:baud = 57600; break;
- case B115200: baud = 115200; break;
- case B230400: baud = 230400; break;
- case B460800: baud = 460800; break;
- default:
- dev_err(port-dev, pl2303 driver does not support
-the baudrate requested (fix it)\n);
- break;
- }
+ baud = tty_get_baud_rate(port-tty);;
dbg(%s - baud = %d, __FUNCTION__, baud);
if (baud) {
buf[0] = baud 0xff;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] visor and whiteheat: remove bogus termios change checks
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/visor.c
linux-2.6.22-rc6-mm1/drivers/usb/serial/visor.c
--- linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/visor.c 2007-07-02
20:50:14.0 +0100
+++ linux-2.6.22-rc6-mm1/drivers/usb/serial/visor.c 2007-07-02
21:25:13.0 +0100
@@ -948,14 +948,6 @@
}
cflag = port-tty-termios-c_cflag;
- /* check that they really want us to change something */
- if (old_termios) {
- if ((cflag == old_termios-c_cflag)
- (RELEVANT_IFLAG(port-tty-termios-c_iflag) ==
RELEVANT_IFLAG(old_termios-c_iflag))) {
- dbg(%s - nothing to change..., __FUNCTION__);
- return;
- }
- }
/* get the byte size */
switch (cflag CSIZE) {
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/whiteheat.c
linux-2.6.22-rc6-mm1/drivers/usb/serial/whiteheat.c
--- linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/whiteheat.c 2007-07-02
20:50:14.0 +0100
+++ linux-2.6.22-rc6-mm1/drivers/usb/serial/whiteheat.c 2007-07-02
21:25:25.0 +0100
@@ -891,15 +891,6 @@
goto exit;
}
- /* check that they really want us to change something */
- if (old_termios) {
- if ((port-tty-termios-c_cflag == old_termios-c_cflag)
- (port-tty-termios-c_iflag == old_termios-c_iflag)) {
- dbg(%s - nothing to change..., __FUNCTION__);
- goto exit;
- }
- }
-
firm_setup_port(port);
exit:
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] mos7720: Remove bogus no termios change check
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/mos7720.c
linux-2.6.22-rc6-mm1/drivers/usb/serial/mos7720.c
--- linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/mos7720.c 2007-07-02
20:50:14.0 +0100
+++ linux-2.6.22-rc6-mm1/drivers/usb/serial/mos7720.c 2007-07-02
21:25:13.0 +0100
@@ -1238,16 +1238,6 @@
return;
}
- /* check that they really want us to change something */
- if (old_termios) {
- if ((cflag == old_termios-c_cflag)
- (RELEVANT_IFLAG(tty-termios-c_iflag) ==
-RELEVANT_IFLAG(old_termios-c_iflag))) {
- dbg(Nothing to change);
- return;
- }
- }
-
dbg(%s - clfag %08x iflag %08x, __FUNCTION__,
tty-termios-c_cflag,
RELEVANT_IFLAG(tty-termios-c_iflag));
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] io_*: Remove bogus termios no change checks
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/io_edgeport.c
linux-2.6.22-rc6-mm1/drivers/usb/serial/io_edgeport.c
--- linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/io_edgeport.c
2007-07-02 20:50:14.0 +0100
+++ linux-2.6.22-rc6-mm1/drivers/usb/serial/io_edgeport.c 2007-07-02
21:12:36.0 +0100
@@ -1513,15 +1513,6 @@
}
cflag = tty-termios-c_cflag;
- /* check that they really want us to change something */
- if (old_termios) {
- if (cflag == old_termios-c_cflag
- tty-termios-c_iflag == old_termios-c_iflag) {
- dbg(%s - nothing to change, __FUNCTION__);
- return;
- }
- }
-
dbg(%s - clfag %08x iflag %08x, __FUNCTION__,
tty-termios-c_cflag, tty-termios-c_iflag);
if (old_termios) {
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/io_ti.c
linux-2.6.22-rc6-mm1/drivers/usb/serial/io_ti.c
--- linux.vanilla-2.6.22-rc6-mm1/drivers/usb/serial/io_ti.c 2007-07-02
20:50:14.0 +0100
+++ linux-2.6.22-rc6-mm1/drivers/usb/serial/io_ti.c 2007-07-02
21:23:37.0 +0100
@@ -2544,14 +2544,6 @@
}
cflag = tty-termios-c_cflag;
- /* check that they really want us to change something */
- if (old_termios) {
- if (cflag == old_termios-c_cflag
- tty-termios-c_iflag == old_termios-c_iflag) {
- dbg (%s - nothing to change, __FUNCTION__);
- return;
- }
- }
dbg(%s - clfag %08x iflag %08x, __FUNCTION__,
tty-termios-c_cflag, tty-termios-c_iflag);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RT-friendly IRQ management in USB
The reason for doing this is historical; usb_hcd_giveback_urb() is documented as running with local IRQs disabled, and many drivers depend on that. For example, their callback routines invoked by usb_hcd_giveback_urb do spin_lock() instead of spin_lock_irqsave(). So what's the best way to do this? Should we do: spin_lock_irqsave(some_lock, flags); ... spin_unlock(some_lock); usb_hcd_giveback_urb(hcd, urb); local_irq_restore(flags); or is there a better approach? Why not just bite the bullet and change the callback convention. The lock verification code should catch the cases that matter and which are overlooked on a code scan. You could also change the name of the callback to be sure it breaks anything out of tree that isn't fixed. Alan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] ark3116.c: Mixed fixups
o Don't parse the cflag for baud rates, its not valid to do so
any more and this driver got it wrong anyway
o Don't do clever termios change checks in drivers and get them
wrong (arguably we should do some smart ones in the tty core but
stty to change nothing is *not* a common or critical path
I don't have the hardware so if you can test this carefully please do. I
thought fixing it up this far was better than marking it and other bits of
USB serial BROKEN
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc4-mm2/drivers/usb/serial/ark3116.c
linux-2.6.22-rc4-mm2/drivers/usb/serial/ark3116.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/usb/serial/ark3116.c 2007-06-07
14:26:00.0 +0100
+++ linux-2.6.22-rc4-mm2/drivers/usb/serial/ark3116.c 2007-06-21
15:57:02.867440512 +0100
@@ -172,7 +172,7 @@
dbg(%s - port %d, __FUNCTION__, port-number);
- if ((!port-tty) || (!port-tty-termios)) {
+ if (!port-tty || !port-tty-termios) {
dbg(%s - no tty structures, __FUNCTION__);
return;
}
@@ -188,16 +188,6 @@
cflag = port-tty-termios-c_cflag;
- /* check that they really want us to change something: */
- if (old_termios) {
- if ((cflag == old_termios-c_cflag)
- (RELEVANT_IFLAG(port-tty-termios-c_iflag) ==
-RELEVANT_IFLAG(old_termios-c_iflag))) {
- dbg(%s - nothing to change..., __FUNCTION__);
- return;
- }
- }
-
buf = kmalloc(1, GFP_KERNEL);
if (!buf) {
dbg(error kmalloc);
@@ -220,7 +210,7 @@
dbg(setting CS7);
break;
default:
- err(CSIZE was set but not CS5-CS8, using CS8!);
+ dbg(CSIZE was set but not CS5-CS8, using CS8!);
/* fall through */
case CS8:
config |= 0x03;
@@ -251,38 +241,33 @@
}
/* set baudrate */
- baud = 0;
- switch (cflag CBAUD) {
- case B0:
- err(can't set 0 baud, using 9600 instead);
+ baud = tty_get_baud_rate(port-tty);
+
+ switch (baud) {
+ case 75:
+ case 150:
+ case 300:
+ case 600:
+ case 1200:
+ case 1800:
+ case 2400:
+ case 4800:
+ case 9600:
+ case 19200:
+ case 38400:
+ case 57600:
+ case 115200:
+ case 230400:
+ case 460800:
break;
- case B75: baud = 75; break;
- case B150: baud = 150; break;
- case B300: baud = 300; break;
- case B600: baud = 600; break;
- case B1200: baud = 1200;break;
- case B1800: baud = 1800;break;
- case B2400: baud = 2400;break;
- case B4800: baud = 4800;break;
- case B9600: baud = 9600;break;
- case B19200:baud = 19200; break;
- case B38400:baud = 38400; break;
- case B57600:baud = 57600; break;
- case B115200: baud = 115200; break;
- case B230400: baud = 230400; break;
- case B460800: baud = 460800; break;
+ /* set 9600 as default (if given baudrate is invalid for
example) */
default:
- dbg(does not support the baudrate requested (fix it));
- break;
+ baud = 9600;
}
- /* set 9600 as default (if given baudrate is invalid for example) */
- if (baud == 0)
- baud = 9600;
-
/*
* found by try'n'error, be careful, maybe there are other options
-* for multiplicator etc!
+* for multiplicator etc! (3.5 for example)
*/
if (baud == 460800)
/* strange, for 460800 the formula is wrong
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] belkin_sa: Various needed fixes
Use the baud rate stuff from the kernel don't parse CBAUD directly
Remove pointless and wrong 'no change' check
Could do with some good testing as well but again better than adding
BROKEN
(The use of BELKIN_SA_BAUD() might seem a bit odd but x/a = b and x/b = a
(rounded for integers)).
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc4-mm2/drivers/usb/serial/belkin_sa.c
linux-2.6.22-rc4-mm2/drivers/usb/serial/belkin_sa.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/usb/serial/belkin_sa.c 2007-06-07
14:24:28.0 +0100
+++ linux-2.6.22-rc4-mm2/drivers/usb/serial/belkin_sa.c 2007-06-21
15:16:52.048940632 +0100
@@ -346,6 +346,7 @@
unsigned long flags;
unsigned long control_state;
int bad_flow_control;
+ speed_t baud;
if ((!port-tty) || (!port-tty-termios)) {
dbg (%s - no tty or termios structure, __FUNCTION__);
@@ -361,16 +362,8 @@
bad_flow_control = priv-bad_flow_control;
spin_unlock_irqrestore(priv-lock, flags);
- /* check that they really want us to change something */
- if (old_termios) {
- if ((cflag == old_termios-c_cflag)
- (RELEVANT_IFLAG(port-tty-termios-c_iflag) ==
RELEVANT_IFLAG(old_termios-c_iflag))) {
- dbg(%s - nothing to change..., __FUNCTION__);
- return;
- }
- old_iflag = old_termios-c_iflag;
- old_cflag = old_termios-c_cflag;
- }
+ old_iflag = old_termios-c_iflag;
+ old_cflag = old_termios-c_cflag;
/* Set the baud rate */
if( (cflagCBAUD) != (old_cflagCBAUD) ) {
@@ -384,38 +377,30 @@
if (BSA_USB_CMD(BELKIN_SA_SET_RTS_REQUEST, 1)
0)
err(Set RTS error);
}
-
- switch(cflag CBAUD) {
- case B0: /* handled below */ break;
- case B300: urb_value = BELKIN_SA_BAUD(300); break;
- case B600: urb_value = BELKIN_SA_BAUD(600); break;
- case B1200: urb_value = BELKIN_SA_BAUD(1200); break;
- case B2400: urb_value = BELKIN_SA_BAUD(2400); break;
- case B4800: urb_value = BELKIN_SA_BAUD(4800); break;
- case B9600: urb_value = BELKIN_SA_BAUD(9600); break;
- case B19200: urb_value = BELKIN_SA_BAUD(19200); break;
- case B38400: urb_value = BELKIN_SA_BAUD(38400); break;
- case B57600: urb_value = BELKIN_SA_BAUD(57600); break;
- case B115200: urb_value = BELKIN_SA_BAUD(115200); break;
- case B230400: urb_value = BELKIN_SA_BAUD(230400); break;
- default: err(BELKIN USB Serial Adapter: unsupported
baudrate request, using default of 9600);
- urb_value = BELKIN_SA_BAUD(9600); break;
- }
- if ((cflag CBAUD) != B0 ) {
- if (BSA_USB_CMD(BELKIN_SA_SET_BAUDRATE_REQUEST,
urb_value) 0)
- err(Set baudrate error);
- } else {
- /* Disable flow control */
- if (BSA_USB_CMD(BELKIN_SA_SET_FLOW_CTRL_REQUEST,
BELKIN_SA_FLOW_NONE) 0)
- err(Disable flowcontrol error);
-
- /* Drop RTS and DTR */
- control_state = ~(TIOCM_DTR | TIOCM_RTS);
- if (BSA_USB_CMD(BELKIN_SA_SET_DTR_REQUEST, 0) 0)
- err(DTR LOW error);
- if (BSA_USB_CMD(BELKIN_SA_SET_RTS_REQUEST, 0) 0)
- err(RTS LOW error);
- }
+ }
+
+ baud = tty_get_baud_rate(port-tty);
+ urb_value = BELKIN_SA_BAUD(baud);
+ /* Clip to maximum speed */
+ if (urb_value == 0)
+ urb_value = 1;
+ /* Turn it back into a resulting real baud rate */
+ baud = BELKIN_SA_BAUD(urb_value);
+ /* FIXME: Once the tty updates are done then push this back to the tty
*/
+
+ if ((cflag CBAUD) != B0 ) {
+ if (BSA_USB_CMD(BELKIN_SA_SET_BAUDRATE_REQUEST, urb_value) 0)
+ err(Set baudrate error);
+ } else {
+ /* Disable flow control */
+ if (BSA_USB_CMD(BELKIN_SA_SET_FLOW_CTRL_REQUEST,
BELKIN_SA_FLOW_NONE) 0)
+ err(Disable flowcontrol error);
+ /* Drop RTS and DTR */
+ control_state = ~(TIOCM_DTR | TIOCM_RTS);
+ if (BSA_USB_CMD(BELKIN_SA_SET_DTR_REQUEST, 0) 0)
+ err(DTR LOW error);
+ if (BSA_USB_CMD(BELKIN_SA_SET_RTS_REQUEST, 0) 0)
+ err(RTS LOW error
[linux-usb-devel] [PATCH] ir_usb: Clean up the worst of it, remove exciting 'crash on open' feature
- Drivers don't call ldisc termios methods. They certainly don't call
them the way this one does - remove wrong call
- The tty buffer code isn't designed to be abused from IRQ handlers and
the new buffering removes the need for the uglies involved - fix them
- Style
- Remove incorrect baud and change handling for termios changes
The driver now has some style, but not a lot - it goes insane if you have
two dongles for example as it continues to use global variables for per
dongle state. That bit isn't my problem.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.22-rc4-mm2/drivers/usb/serial/ir-usb.c
linux-2.6.22-rc4-mm2/drivers/usb/serial/ir-usb.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/usb/serial/ir-usb.c2007-06-07
14:24:28.0 +0100
+++ linux-2.6.22-rc4-mm2/drivers/usb/serial/ir-usb.c2007-06-21
14:03:05.731843112 +0100
@@ -21,6 +21,10 @@
*
* See Documentation/usb/usb-serial.txt for more information on using this
driver
*
+ * 2007_Jun_21 Alan Cox [EMAIL PROTECTED]
+ * Minimal cleanups for some of the driver problens and tty layer abuse.
+ * Still needs fixing to allow multiple dongles.
+ *
* 2002_Mar_07 greg kh
* moved some needed structures and #define values from the
* net/irda/irda-usb.h file into our file, as we don't want to depend on
@@ -109,6 +113,7 @@
static void ir_read_bulk_callback (struct urb *urb);
static void ir_set_termios (struct usb_serial_port *port, struct ktermios
*old_termios);
+/* Not that this lot means you can only have one per system */
static u8 ir_baud = 0;
static u8 ir_xbof = 0;
static u8 ir_add_bof = 0;
@@ -444,22 +449,12 @@
urb-actual_length,
data);
- /*
-* Bypass flip-buffers, and feed the ldisc directly
-* due to our potentially large buffer size. Since we
-* used to set low_latency, this is exactly what the
-* tty layer did anyway :)
-*/
tty = port-tty;
- /*
-* FIXME: must not do this in IRQ context
-*/
- tty-ldisc.receive_buf(
- tty,
- data+1,
- NULL,
- urb-actual_length-1);
+ if (tty_buffer_request_room(tty, urb-actual_length -
1)) {
+ tty_insert_flip_string(tty, data+1,
urb-actual_length - 1);
+ tty_flip_buffer_push(tty);
+ }
/*
* No break here.
@@ -501,8 +496,9 @@
static void ir_set_termios (struct usb_serial_port *port, struct ktermios
*old_termios)
{
unsigned char *transfer_buffer;
- unsigned int cflag;
int result;
+ speed_t baud;
+ int ir_baud;
dbg(%s - port %d, __FUNCTION__, port-number);
@@ -511,77 +507,59 @@
return;
}
- cflag = port-tty-termios-c_cflag;
- /* check that they really want us to change something */
- if (old_termios) {
- if ((cflag == old_termios-c_cflag)
- (RELEVANT_IFLAG(port-tty-termios-c_iflag) ==
RELEVANT_IFLAG(old_termios-c_iflag))) {
- dbg(%s - nothing to change..., __FUNCTION__);
- return;
- }
+ baud = tty_get_baud_rate(port-tty);
+
+ /*
+* FIXME, we should compare the baud request against the
+* capability stated in the IR header that we got in the
+* startup function.
+*/
+
+ switch (baud) {
+ case 2400: ir_baud = SPEED_2400; break;
+ case 9600: ir_baud = SPEED_9600; break;
+ case 19200: ir_baud = SPEED_19200; break;
+ case 38400: ir_baud = SPEED_38400; break;
+ case 57600: ir_baud = SPEED_57600; break;
+ case 115200:ir_baud = SPEED_115200; break;
+ case 576000:ir_baud = SPEED_576000; break;
+ case 1152000: ir_baud = SPEED_1152000; break;
+ case 400: ir_baud = SPEED_400; break;
+ break;
+ default:
+ ir_baud = SPEED_9600;
+ baud = 9600;
+ /* And once the new tty stuff is all done we need to
+ call back to correct the baud bits */
}
- /* All we can change is the baud rate */
- if (cflag CBAUD) {
+ if (xbof == -1)
+ ir_xbof = ir_xbof_change(ir_add_bof);
+ else
+ ir_xbof = ir_xbof_change(xbof) ;
- dbg (%s
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
Disk dumps etc are options at things like wall street. But look at the bug reports, and ask yourself how many of them happen at Wall Street, and how many of them would even be _relevant_ to somebody there? There is an additional factor - dumps contain data which variously is - copyright third parties, protected by privacy laws, just personally private, security sensitive (eg browser history) and so on. The only reasons you can get dumps back in the hands of vendors is because there are strong formal agreements controlling where they go and what is done with them. Diskdump (and even more so netdump) are useful in the hands of a developer crashing their own box just like kgdb, but not in the the normal and rational end user response of its broken, hit reset Alan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/3] 2.6.22-rc2: known regressions v2
On Fri, May 25, 2007 at 10:37:14AM -0700, Andrew Morton wrote: Often we don't even get that: I was in X and it didn't hit the logs. Thats mostly solved by fixing the Oops and framebuffer code to co-operate and is a different problem Alan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Please reactivate your Yahoo! Groups email address
On Tue, 22 May 2007 15:53:23 -0700 David Brownell [EMAIL PROTECTED] wrote: Does anyone have a clue about how to get Yahoo to stop spamming us all with this stuff? Their abuse hotline is completely nonresponsive. Short of publically humiliating them or happening to know the right people (sorry I don't any more) no. You can match yahoo messages in the mailman rules for stuff not to allow - and if you match the subscribe pattern as well it stops spammers trying to add your list to their lists (which is what all this is about) Alan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 1/4] Make usb_hcd_irq available for multi-role USB controllers with a shared interrupt line
For ohci-hcd, we used -1. The problem here is, while IRQ 0 is definitely not valid for PCI devices (as Alan Cox reminded me a couple of weeks ago), USB controllers are found in odd embedded configurations often, so we cannot just use 0 as invalid everywhere. I don't know if -1 is good though. Seems like it should be. Alan Cox also cautioned against using NO_IRQ, because it's not universally defined by all platforms, and in general is an invention of old IDE. Looks like -1 is the way to go. Zero means no IRQ in the kernel. No platform should be reporting an IRQ number of zero, the platform has to re-map it should there be a physical IRQ 0 used by drivers. Alan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH pd54] Remove Huawei unusual_devs entry
I also agree with Alan Cox that that specific software should be found in, as stated, on well known locations, and distributed by vendors. It seems that we do have a few people from Huawei that can help us try to achieve that. I'll try to CC all of them. Ok here's a serious suggestion to go forward Submit a patch for now which makes the Huwaei unusual devs entry conditional on a config entry so you can select Support Huawei USB virtual CD-ROM on the Huawei E220 Y/N This option enables the virtual CD-ROM support for the Huawei E220. In order to use this option you need the Huawei tools which can be downloaded from: [somewhere well known] and clean the userspace up so that - The firmware license is sorted - The userspace app includes instructions/basic info in English as well as Czech(?) - The userspace integrates directly with the udev scripts so it is run automatically if added Once the userspace is sane and in all the distributions the configuration option can eventually go away. Alan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH pd54] Remove Huawei unusual_devs entry
On Sun, 15 Apr 2007 23:42:40 -0700 Phil Dibowitz [EMAIL PROTECTED] wrote: Greg, This patch removes the entry for the Huawei patch at the request of the manufacturers and other users. See the patch for the full explanation, CC's, and sign-off. Please apply. The program pointed to is not remotely production quality, its a random small piece of source with no English language information not distributed by vendors. Until there is a good clean tool for this which is found in well known locations and documented/production standardard (which is not the same thing as 'working') this change should be deferred - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH]correctly handling failed opens in usb-serial
On Thu, 29 Mar 2007 14:29:07 -0700 Greg KH [EMAIL PROTECTED] wrote: On Thu, Mar 29, 2007 at 10:15:00AM +0200, Oliver Neukum wrote: Hi, as recently discussed on lkml the tty layer does call close() if an open() fails. Usb-serial does not handle this correctly. It does handle the first open() failing by checking the open count, but if a second open() fails, the close() will free the resources associated with the first open. Why can't we just fix the tty layer instead? Feel free, it just needs all existing serial drivers to be audited for dependancies on the old behaviour and corrected. Painful, tedious work but possibly worth doing - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 2.6.20 1/1] usb/input updated aiptek tablet driver
+ * Extra bits2004 René van Paassen [EMAIL PROTECTED] +#define DRIVER_AUTHOR Bryan W. Headley/Chris Atenasio/Cédric Brun/René van Paassen Please understand, patches are commonly sent naked in the mail, even in this enlightened day of git and MIME. So, even if you send it right, eventually someone else will patch your code, diff context will catch the name, and... What is the problem. His name contains an accented character. We have various other UTF-8 accented symbols in the kernel tree. I don't think its reasonable to suggest we go around mis-spelling contributors names (which are after all for the purposes of credit and copyright), just because a few people can't get with the real world and unicode. Alan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Firmware for new ti_usb_3410_5052 devices (resend with subject)
So if you are accepting a firmware into the kernel, watch closely how it's being used. Tracking static symbols vs. buffer's content from request_firmware() can be harder, i think. For things like USB the firmware question of security is pretty irrelevant. If I can feed the device wrong firmware and have the device attack the kernel then the kernel driver is faulty and needs correcting. USB is an external removable device so if there is a way to feed a device messages that cause exploits I can simply build a widget to do it and not bother at all with attacking the host firmware files - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Firmware for new ti_usb_3410_5052 devices (resend with subject)
Is it ok to include the 5 new firmware images in the ti_usb_3410_5052 driver as .h files? Or should I use request_firmware? As far as i can see: userspace firmware helper is orphan, Greg advertise himself for writing new drivers, all is working *somehow*, it will be OK to have another few tenth of kibibytes in this driver... Unless the firmware is GPL with source please use request_firmware(), otherwise you are getting into unclear areas with regards to licensing. Although the loader has no full time maintainer that doesn't mean it doesn't work - quite the reverse, it doesn't seem to be breaking. Alan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB performance bug since kernel 2.6.13 (CRITICAL???)
Ar Gwe, 2006-10-13 am 16:02 -0700, ysgrifennodd Open Source: clear understanding of what is causing it. As it stands it doesn't seem like even the experts know exactly where this delay is being caused. strace should tell you precisely how long each syscall takes if you ask it to trace things nicely. If you have code trying to wait for a tiny time then HZ will bump the wait to be longer (kernel or user) but for other cases all should be fine either way. The other issues like priority and paging caused delays can generally be dealt with by having the relevant service code running mlockall and real time priority. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB performance bug since kernel 2.6.13 (CRITICAL???)
Ar Gwe, 2006-10-13 am 16:30 -0700, ysgrifennodd Open Source: There is an ioctl that is waiting for the URB to be reaped. I am almost certain it is this syscall that is taking 4 ms (as opposed to 1 ms with CONFIG_HZ=1000). What does strace say about it ? This is measurable not speculation. Will the first piece of code wake up immediately or only after the next HZ timeslice? If it is the latter, which is what I am starting to It depends if there are other things running and on their priority relative to you. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] ohci: Use ref-counting hotplug safe interfaces not legacy ones
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.18-mm1/drivers/usb/host/ohci-pci.c
linux-2.6.18-mm1/drivers/usb/host/ohci-pci.c
--- linux.vanilla-2.6.18-mm1/drivers/usb/host/ohci-pci.c2006-09-25
12:10:17.0 +0100
+++ linux-2.6.18-mm1/drivers/usb/host/ohci-pci.c2006-09-25
12:26:26.0 +0100
@@ -73,13 +73,14 @@
else if (pdev-vendor == PCI_VENDOR_ID_NS) {
struct pci_dev *b;
- b = pci_find_slot (pdev-bus-number,
+ b = pci_get_slot (pdev-bus,
PCI_DEVFN (PCI_SLOT (pdev-devfn), 1));
if (b b-device == PCI_DEVICE_ID_NS_87560_LIO
b-vendor == PCI_VENDOR_ID_NS) {
ohci-flags |= OHCI_QUIRK_SUPERIO;
ohci_dbg (ohci, Using NSC SuperIO setup\n);
}
+ pci_dev_put(b);
}
/* Check for Compaq's ZFMicro chipset, which needs short
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Airprime driver improvements to allow full speed EvDO transfers
On Iau, 2006-07-13 at 18:17 +0400, Sergei Organov wrote: This problem may occur with any tty driver that doesn't stop to insert data into the tty buffers in throttled state. And yes, there are such drivers in the tree. Before Paul's changes, the tty just dropped bytes that aren't accepted by ldisc, so this problem had no chances to arise. You must honour throttle. That has always been the case. At all times you should attempt to homour tty-receive_room and also -throttle. If you don't it breaks. There will always be some reaction time overruns. latter cases drivers that insert too much data without pushing to ldisc may cause similar problem. Anyway, you definitely know better what to do about it. Might be a good idea to put a limiter in before 2.6.18 proper just to trap any other drivers that have that bug. At least printk a warning and refuse the allocation once there is say 64K queued. That way the driver author gets a hint all is not well. Alan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Airprime driver improvements to allow full speed EvDO transfers
Ar Llu, 2006-07-10 am 14:36 +0400, ysgrifennodd Sergei Organov:
However, the problem is easily seen for USB-to-tty drivers where there
are no UARTS anywhere and speeds are rather high so that more than 4096
bytes (the line discipline buffer size) could be received before a task
has a chance to read from the line discipline buffer, and single flip
size is not limited by the hardware.
There are no flip buffers in 2.6.17, they've gone. The tty buffering is
now a proper queuing system.
Moreover, looking into the source code I don't see how tty can take care
not to over-stuff the ldisc. ldisc`s receive_buf() routine doesn't tell
the caller how many chars it actually consumed and silently throws away
Not in the current kernel tree. The current tree does this:
spin_lock_irqsave(tty-buf.lock, flags);
head = tty-buf.head;
if (head != NULL) {
tty-buf.head = NULL;
for (;;) {
int count = head-commit - head-read;
if (!count) {
if (head-next == NULL)
break;
tbuf = head;
head = head-next;
tty_buffer_free(tty, tbuf);
continue;
}
if (!tty-receive_room) {
schedule_delayed_work(tty-buf.work, 1);
break;
}
if (count tty-receive_room)
count = tty-receive_room;
char_buf = head-char_buf_ptr + head-read;
flag_buf = head-flag_buf_ptr + head-read;
head-read += count;
spin_unlock_irqrestore(tty-buf.lock, flags);
disc-receive_buf(tty, char_buf, flag_buf, count);
spin_lock_irqsave(tty-buf.lock, flags);
}
tty-buf.head = head;
}
spin_unlock_irqrestore(tty-buf.lock, flags);
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Airprime driver improvements to allow full speed EvDO transfers
Ar Llu, 2006-07-10 am 19:54 +0400, ysgrifennodd Sergei Organov: Wow! The code you've quoted seems to be correct! But where did you get it from? The version of flush_to_ldisc() from drivers/char/tty_io.c from 2.17.4 got last Friday from kernel.org does this: From HEAD so it should make 2.6.18. Paul fixed this one. Alan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Airprime driver improvements to allow full speed EvDO transfers
Ar Gwe, 2006-07-07 am 21:23 +0400, ysgrifennodd Sergei Organov: It seems that there is much worse problem here. The amount of data that has been inserted by the tty_insert_flip_string() could be up to URB_TRANSFER_BUFFER_SIZE (=4096 bytes) and may easily exceed TTY_THRESHOLD_THROTTLE (=128 bytes) defined in the char/n_tty.c. You may throttle late but that is always true as there is an implicit race between the hardware signals and the chip FIFO on all UART devices. The buffering should be taking care of it, and the tty layer taking care not to over stuff the ldisc which I thought Paul had fixed while doing the locking wizardry Alan Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Airprime driver improvements to allow full speed EvDO transfers
Ar Gwe, 2006-06-30 am 14:51 +0400, ysgrifennodd Sergei Organov: In fact, according to Alan Cox answer, the first call is useless here at all, i.e., tty_buffer_request_room() is for subsequent tty_insert_flip_char() calls in a loop, not for tty_insert_flip_string(). tty_insert_flip_string() calls tty_buffer_request_room() itself, and does it in a loop in attempt to find as much memory as possible. Yep. Think of it as a hint that I'm about to stuff xyz bytes into memory to get best memory efficiency. tty_insert_flip_string() returns number of bytes it has actually inserted, but I don't believe one can do much if it returns less than has been requested as it means that we are out of kernel memory. Yes. I've been wondering if we should log the failure case somewhere, either as a tty- object or printk. Alan Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Airprime driver improvements to allow full speed EvDO transfers
Ar Gwe, 2006-06-30 am 14:02 +0200, ysgrifennodd Arjan van de Ven: Yes. I've been wondering if we should log the failure case somewhere, either as a tty- object or printk. printk gets... interesting if you use serial console ;) both locking and buffer space wise Not particularly. This is on the receive path not the transmit path so the locking considerations don't arise. Alan Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB/hal: USB open() broken? (USB CD burner underruns, USB HDD hard resets)
Ar Mer, 2006-06-21 am 02:07 +0200, ysgrifennodd Bodo Eggert: This does not work, since O_EXCL does not work: http://lkml.org/lkml/2006/2/5/137 It works fine. Its an advisory exclusive locking scheme which is precisely what is needed and precisely how some vendors implement their solution. There are good reasons for not having absolute locks, one of which is that you might want to force a reset or a hot unplug of an interface knowing you'll lose the CD its burning (eg because your flight is about to leave) Alan ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB/hal: USB open() broken? (USB CD burner underruns, USB HDD hard resets)
Ar Mer, 2006-06-21 am 15:02 -0400, ysgrifennodd Alan Stern: It's not a USB issue; it's a matter of lack of coordination between the sg and sr drivers. Each is unaware of the actions of the other, even when they are speaking to the same device. Thats a relevant issue but sg is irrelevant for cd burning except with various ancient software setups. Probably sg/sr should share the O_EXCL locking but its not part of the cd burning stuff for modern setups. Alan All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB/hal: USB open() broken? (USB CD burner underruns, USB HDD hard resets)
Ar Mer, 2006-06-21 am 15:06 -0400, ysgrifennodd Alan Stern: cdrecord is -dev=0,0,0 (whatever Linux device file this translates into) or a similar device ID as returned by -scanbus. That goes through the sg driver. Use a cdrecord that understands SG_IO and dev=/dev/sr0 All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB/hal: USB open() broken? (USB CD burner underruns, USB HDD hard resets)
Ar Maw, 2006-06-20 am 01:37 -0700, ysgrifennodd Andrew Morton: [hald polling causes cdrecord to go bad on a USB CD drive] One possible reason is that we're shooting down the device's pagecache by accident as a result of hald activity. On IDE hal causes problems with some drives because the additional commands sent while the drive is busy end up timing out which triggers a bus reset and breaks everything. Really HAL should have better manners than to poll a drive that is busy. Alan ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB/hal: USB open() broken? (USB CD burner underruns, USB HDD hard resets)
Ar Maw, 2006-06-20 am 11:05 +0200, ysgrifennodd Andreas Mohr: But how would HAL safely determine whether a (IDE/USB) drive is busy? As my test app demonstrates (without HAL running), the *very first* open() happening during an ongoing burning operation will kill it instantly, in the USB case. Are there any options left for HAL at all? Still seems to strongly point towards a kernel issue so far. In the IDE space O_EXCL has the needed semantics. At least it does on Fedora and I don't think thats a Fedora patch, not sure if this is the case for the USB side of things. One (rather less desireable) way I can make up might be to have HAL keep the device open permanently and do an ioctl query on whether it's busy and then quickly close the device again before the newly started burning process gets disrupted (if this even properly works at all). O_EXCL used by cdrecord is probably the right thing ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 8/11] usbserial: pl2303: Ports tty functions.
| 2. The new pl2303's set_termios() can (still) sleep. Serial Core's | documentation says that that method must not sleep, but I couldn't find | where in the Serial Core code it's called in atomic context. So, is this | still true? Isn't the Serial Core's documentation out of date? For the tty layer at least this was fixed to be semaphore locked and I think this is now a docs error. It was fixed precisely because the USB people couldn't resolve termios setup without sleeping. ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ANNOUNCE: Linux UWB and Wireless USB project
Ar Llu, 2006-06-05 am 13:31 -0700, ysgrifennodd Perez-Gonzalez, Inaky: For what I know (and I could be wrong) max is around -40dBm/MHz in the US. I am no expert in the nitty-gritty radio details, but I've been told that is 3000 times less emissions than a common cellphone, around .1 uW? [this is where my knowledge about radio *really* fades]. Life is never that simple. The total emissions of UWB are pretty low but their spread across the wide frequency range makes them incredibly low on any frequency - so very unlikely to interfere. The total emissions across the set of frequencies as a sum (with emphasis on some frequency ranges such as 2.4-2.5GHz) apparently matters much more than the emissions at one frequency for things like human exposure. Alan ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [usb-storage] Re: [v4l-dvb-maintainer] 2.6.16-rc: saa7134 + u sb-storage = freeze
On Thu, Mar 16, 2006 at 12:49:18AM +0100, Adrian Bunk wrote: A lot of this is BIOS dependant and if we can isolate cases where one BIOS works and another doesn't an lspci -vvxxx would be helpful so we can look for chipset pokery It's below. Vendor fix went to the ide maintainer and to me for the libata ALi driver so ATA/ATAPI should all work now. Not clear if that also fixes the non IDE cases but would be useful to know --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [usb-storage] Re: [v4l-dvb-maintainer] 2.6.16-rc: saa7134 + u sb-storage = freeze
On Fri, Mar 17, 2006 at 09:59:44AM -0600, Ballentine, Casey wrote: Attached please find the output of lspci -vvxxx using the released 1.05 BIOS and the 1.05 test BIOS on a VIA EPIA PD-1 mainboard (CLE266 northbridge and vt8235 southbridge). Hopefully this will shed some light on what VIA is doing. Let me know if I can provide more information. Ok the changes in the PCI space are 82C586_1: 0x70 was 0x22: now 0x42 8235(South) : 0x91 was 0x00 now 0x03 862X(North) : 0x61 was 2a now ea 0x62 was 00 now 03 0x68 was 0xD1 now 0xCA 0x81 was 0x61 now 0x69 8235 0x91 is just general purpose timer control 82C586_1 0x70 is an IDE status bit So the changes that matter are those (or some of those) on the 862X. Which is the one bit I don't have docs on --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [usb-storage] Re: [v4l-dvb-maintainer] 2.6.16-rc: saa7134 + u sb-storage = freeze
On Thu, Mar 16, 2006 at 04:55:11PM -0300, Mauro Carvalho Chehab wrote: Em Qua, 2006-03-15 Ã s 18:44 -0500, Alan Cox escreveu: On Wed, Mar 15, 2006 at 03:24:40PM -0600, Ballentine, Casey wrote: I would bet we could add the vt8235 to the list of broken chipsets as well, if it's not already there. My company has completely Works for me 8) On overlay mode? Weird! May depend on the northbridge not the south, or the combination of course VIA just posted some BIOS updates. If we can get the before and after we can probably figure it out. If not then once the new BIOSes go from beta it'll be a case of poking via gently for info --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [usb-storage] Re: [v4l-dvb-maintainer] 2.6.16-rc: saa7134 + u sb-storage = freeze
On Wed, Mar 15, 2006 at 03:24:40PM -0600, Ballentine, Casey wrote: I would bet we could add the vt8235 to the list of broken chipsets as well, if it's not already there. My company has completely Works for me 8) A lot of this is BIOS dependant and if we can isolate cases where one BIOS works and another doesn't an lspci -vvxxx would be helpful so we can look for chipset pokery --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Bad OHCI USB handoff and i8042 interaction
On Mer, 2006-02-01 at 11:47 -0500, Alan Stern wrote: Dmitry: These two bug reports appear to be the same problem: http://bugzilla.kernel.org/show_bug.cgi?id=4791 http://bugzilla.kernel.org/show_bug.cgi?id=5932 My feeling is that there's no way to change the OHCI usb-handoff code so that it will work with these buggy BIOSes. The reason the problem is showing up now is probably an order-of-execution thing. Previously the i8042 would be initialized before the USB handoff, so it worked okay. Now the i8042 initialization occurs after the USB handoff, so it fails. The older Red Hat code triggers the USB handoff setup from the i8042 setup at the point the i8042 appears to be talking through its backside. Seems to be no reason for the non modular case the same cannot be done now (or done for all cases if need be) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: BUG?: VIA IDE transfer-rate problem
On Iau, 2006-01-19 at 00:41 +0100, Helmut Toplitzer wrote: Ok. Was just a bit digging through the sourcecode. Found a function called disable_hlt. Some further digging. Found in drivers/block/floppy.c a usage of disable_hlt. It's called (if I haven't missunderstood something) whenever a DMA transfer is setup. enable_hlt is called when a transfer stops/is cancled etc... Yes this deals with some errata cases Does such thing makes sense for IDE DMA-transfers too? (Maybe I've missed something) Only for the CS5510 Cyrix as far as I know, and I really ought to fix that in the new libata driver. Generally speaking hlt is good, it takes the CPU off the bus and frees it up for the other users. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [2.6 patch] remove unused tmp_buf_sem's
On Gwe, 2006-01-13 at 19:49 -0800, Greg KH wrote: On Sat, Jan 14, 2006 at 03:08:16AM +0100, Adrian Bunk wrote: -- snip -- tmp_buf_sem sems to be a common name for something completely unused... That would be correct. The old tty driver layer used to call -write from both kernel and user contexts according to a flag. Drivers then all ended up with the same code copying it into a tmp buffer and using a locking semaphore. Linus took out that code and arranged that -write always got a kernel buffer so the remainders should indeed go. Alan --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch]cleanup of usblp
On Sad, 2006-01-07 at 15:21 -0800, Pete Zaitcev wrote: On Sat, 07 Jan 2006 23:11:07 +, Alan Cox [EMAIL PROTECTED] wrote: wait_event(tty_ldisc_wait, tty_ldisc_try(tty)); That is more or less all right, I agree. It is still somewhat limited because the lock cannot be held across the loop into its body, so actions cannot be taken atomically with the condition. If that is the needed case you do something like wait_event(foo_wait, foo_and_lock(foo)); blah unlock(foo) Alan --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch]cleanup of usblp
On Sad, 2006-01-07 at 14:18 -0800, Pete Zaitcev wrote: Using wait_for_event is never an improvement. It's just a retarded API, which allows you to save lines-of-code count at expense of being opaque and conflicting with proper locking. Used properly it makes things very clear. In particular lots of code ends up with a function that figures out if it can make progress. Use that function as the wait_event argument. See the tty drivers which do this. wait_event(tty_ldisc_wait, tty_ldisc_try(tty)); is pretty explicit. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: need for packed attribute
On Gwe, 2006-01-06 at 12:23 -0800, Pete Zaitcev wrote: or it is just a bug which didn't reach gcc people yet. It is dysfunctional to have structures padded in this way. On all other platforms they are only padded if they include a member which is bigger than the char. Not true. Maybe for the other platforms we support today but a large number of compilers have used 2 or 4 byte alignment for all object starts, especially little endian word addressed systems. I suspect ucLinux as it hits bigger DSP oriented devices will find more examples. Russell is right on this one. If you want an object to be aligned as you lay it out use attribute packed either on the struct or the relevant fields. Alan --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 1/1] g_file_storage: emulate SCSI CDROM instead of disk ('true read-only') for 'ro=1' option
On Iau, 2005-12-08 at 11:00 -0500, Alan Stern wrote: module parameter. For some reason (don't ask me why -- I don't know) the SCSI core doesn't check a disk device's write-protect status unless the device is marked as removable. Have you asked the scsi maintainers why this occurs. Having had a quick look over the specs I have here I can't see why this is done either. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
On Mer, 2005-12-07 at 16:50 +0100, Oliver Neukum wrote: But the atomic variant has to guard against interrupts, at least on architectures that do load/store only, hasn't it? Yes. And you will see at least four different approaches 1. ll/sc where if the sequence was interrupted and may be stale it gets retried 2. locked operations where the IRQ cannot split the sequence and use of 3. spin locks to provide atomic operations where there are architecture limits 4. Use of instructions acting on memory where the CPU in question has them and (as is usual in processors) does not permit an IRQ mid instruction. Thus on x86 *foo++ might be atomic, might not on uniprocessor v interrupt solely because the compiler chooses the operations. Atomic_inc however merely has to use asm to force an inc of a memory location target. That instruction cannot be split part way by an interrupt so is sufficient. Relative efficiency of spin_lock versus atomic_foo is very platform dependant. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] cdc-acm.c in 2.6.14-mm1
On Maw, 2005-11-08 at 15:06 +0100, Oliver Neukum wrote: Am Dienstag, 8. November 2005 00:47 schrieb Andrew Morton: Guys, I had to fix a clash between recent changes in this file and Alan's rework of the tty buffering scheme. I'm not 100% confident in the result. Are the change to the tty layer documented somewhere? Linux-kernel July 21st - pasted again below. Since then _flags variants have been added which let you do blocks of data + flags. The big thing is that the tty layer now does real buffering so all the horrible driver hacks can go away. - At the moment tty buffers are attached directly to the tty. This is causing a lot of the problems related to tty layer locking, also problems at high speed and also with bursty data (such as occurs in virtualised environments) I'm working on ripping out the flip buffers and replacing them with a pool of dynamically allocated buffers. This allows both for old style byte I/O devices and also helps virtualisation and smart devices where large blocks of data suddenely materialise and need storing. So far so good. Lots of drivers reference tty-flip.*. Several of them also call directly and unsafely into function pointers it provides. This will all break. Most drivers can use tty_insert_flip_char which can be kept as an API but others need more. At the moment I've added the following interfaces, if people think more will be needed now is a good time to say int tty_buffer_request_room(tty, size) Try and ensure at least size bytes are available, returns actual room (may be zero). At the moment it just uses the flipbuf space but that will change. Repeated calls without characters being added are not cumulative. (ie if you call it with 1, 1, 1, and then 4 you'll have four characters of space. The other functions will also try and grow buffers in future but this will be a more efficient way when you know block sizes. int tty_insert_flip_char(tty, ch, flag) As before insert a character if there is room. Now returns 1 for success, 0 for failure. int tty_insert_flip_string(tty, str, len) Insert a block of non error characters. Returns the number inserted. int tty_prepare_flip_string(tty, strptr, len) Adjust the buffer to allow len characters to be added. Returns a buffer pointer in strptr and the length available. This allows for hardware that needs to use functions like insl or mencpy_fromio. I've converted a fair number of drivers to this API ready and I'll post some patches for review soon. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Commit [PATCH] USB: Always do usb-handoff breaks my powerbook
On Maw, 2005-11-01 at 14:30 +1100, Benjamin Herrenschmidt wrote: Damn, those quirks should really be either more careful or be made platform specific if they are x86 junk workarounds. USB handoff is fairly x86 specific. The x86 folks took great care to handle back compatibility while Apple was content to just dump the users and machines. It is illegal, whatever the platform is, to tap a PCI device MMIO like Not illegal - invalid. Please get that right as we have far too many incorrect uses of illegal in publically visible printk calls. Illegal means prohibited by law. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH 01/04] USB: add notifier
On Mer, 2005-10-19 at 14:21 -0700, gary clark wrote: The reasons why I want to do this without breaking a confidentiality agreement is to not let the user know that I have disabled/enabled the USB devices. I dont want it in user space, simply because he can kill the app with ease...in kernel space well thats a bit more tricky. The user cannot easily kill a root owned process only their own. And if you are trying to stop the device owner from accessing their own hardware then I hope you have good lawyers. It's hard to give any advice with such little info - the threat model is critical to this, whether it is something like POS and disabling unauthorised devices on a cash till, whether it is virtualisation or even security devices. Alan --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [Security] Re: [linux-usb-devel] Re: [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Tue, Oct 11, 2005 at 03:13:39PM -0400, Alan Stern wrote: Surely Linux uses entirely original code, with no hangovers from the original ATT Unix... Besides, to the best of my recollection, the two operations are equal in speed on a PDP-11. I've no idea but I don't believe the relative speed of PDP_11 operations is security critical in Linux so can you trim the cc line --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [Security] [vendor-sec] [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Maw, 2005-09-27 at 09:09 -0700, Linus Torvalds wrote: root-owned), then the urb completes, and kill_proc_info() sends the signal to the unsuspecting process. Ehh.. pid's don't get re-used until they wrap. Which doesn't take very long to arrange. Relying on pids is definitely a security problem we don't want to make worse than it already is. If you look it up by pid, it won't be stale, now will it? Just potentially wrong, but if it uses the SIGIO code and the SIGIO code is fixed then it works out. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [Security] [vendor-sec] [BUG/PATCH/RFC] Oops while completing async USB via usbdevio
On Maw, 2005-09-27 at 09:59 -0700, Linus Torvalds wrote: On Tue, 27 Sep 2005, Alan Cox wrote: Which doesn't take very long to arrange. Relying on pids is definitely a security problem we don't want to make worse than it already is. The thing is, the current code is _worse_. MUCH worse. Violent agreement --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: PATCH: decreasing latency for FT232BM
1. if low_latency flag isn't set we don't care about hardware latency. 2. if we're in canonical mode, assume theres a human on the other end. 3. VTIME only applies in non-canonical mode. 4. Any VTIME value greater than 0 corresponds to at least 100 ms, so we don't care about low hardware latency. And your heuristic is wrong for ppp on slower boxes. tty flip buffer contents are processed after receiving data. In low-latency mode the contents are processed immediately, but in normal-latency mode a task was scheduled to process the contents. At The former can cause problems on slower boxes because the processing is done at IRQ level. high receive rates, this could result in data being thrown away because the flip buffer hadn't flipped yet. Flip buffers are history in 2.6-mm so that aspect is done and buried --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Lost keyboard on Inspiron 8200 at 2.6.13
On Sad, 2005-09-17 at 00:12 -0400, Alan Stern wrote: Where does early handoff install a fake interrupt handler for UHCI? I don't see any in drivers/pci/quirks.c. Fedora patches for 2.6.9 rather than the current code. You need them because an IRQ could be pending on the channel at the point you switch over or triggered on the switch and a few people saw this behaviour. Yes, that would be needed if you have edge-triggered interrupts. But isn't PCI supposed to be level-triggered? Yes and at the time several people saw hangs on the changeover unless we cleared pending IRQ bits in the IRQ handler. That may have been related to various ACPI problems from back then. I don't know for sure. I'd like to see it shared but that means handoff belongs in the input layer code and the USB layer needs to call into it if appropriate. Why does it mean that? And why the input layer as opposed to the PCI layer, where it is now? PCI layer makes even more sense yes --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Lost keyboard on Inspiron 8200 at 2.6.13
On Gwe, 2005-09-16 at 15:24 -0700, Pete Zaitcev wrote: I see why you would want to merge them, but is it worth the trouble? They are not identical. For one thing, early handoff installs its own fake interrupt handlers (Alan Cox insisted on it in the RHEL implementation). You need them because an IRQ could be pending on the channel at the point you switch over or triggered on the switch and a few people saw this behaviour. I'd like to see it shared but that means handoff belongs in the input layer code and the USB layer needs to call into it if appropriate. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] imx usb gadget controller driver
On Maw, 2005-08-30 at 11:14 +0530, [EMAIL PROTECTED] wrote: Now we have to upgrade to update 1 from Red Hat. We tried with Update 1 and kernel version for this is 2.6.9-11. But with this kernel disconnecting mobile works fine for the first time after that it's giving kernel panic and I tried some 3-4 times after that system is crashed. Since disconnecting is common functionality and always we are facing kernel panic with this function. Please give us suggestions on this. You should raise Red Hat Enterprise Linux problems with your Red Hat support contact. That way they will reach the people you are paying to support it, and who know the code variant best. Alan --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] CDC-ACM class driver/driver development
On Sad, 2005-08-27 at 21:49 -0700, Pete Zaitcev wrote: The size of flip buffers, I expect. And you cannot flip them too often. I sent Andrew Morton the patches to fix all the tty layer buffering limits by replacing the flip buffers with kmalloc managed rings of buffers. I've not heard back so I'll poke him about it again soon in case it got eaten by OSDL's rather dodgy spam filters. 3. In case no standard class driver works out, which kernel driver do you recommend for study? I'd need a high speed/low delay IN and OUT channel The tty layer btw is designed for batching rather than low latency. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: USB: pwc driver removal
On Maw, 2005-03-15 at 17:40, Greg KH wrote: Please start sending me patches to fix it up, as it has a number of issues. You can find it in the nightly -bk snapshots on kernel.org. Send patches to the maintainer not to GregKH please. There is a subversion tree of the development work. Also send the v4l2 library patches that go with the kernel changes to the V4L maintainers. If stuff goes around the SV tree mayhem will occur. Alan --- 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=6595alloc_id=14396op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB: pwc driver removal
On Maw, 2005-03-15 at 17:20, Luca Risolia wrote: Greg, after many months since the inclusion in -ac tree, the pwc driver in the -mm tree _still_ implements decompression in kernelspace, which is depecrated. I think this matter has been already discussed in the lkml. The driver is an ongoing work. It now has open source decompressors but hasn't yet acquired all the v4l2 stuff and the decompressor move to user space (IF that makes sense as the decode is not a standard one). It can't move until V4L2 user space has moved. Alan --- 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=6595alloc_id=14396op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: USB: pwc driver removal
On Maw, 2005-03-15 at 21:07, Luca Risolia wrote: If you want, I will send a patch to fix the kernel up by removing the driver at all, otherwise be also prepared to accept any decompressors I might submit in the future. How about behaving like an adult instead ? I don't see why pwc is a particular case. V4L2 is enough for the decompression to be done in userspace; there is one example under usb/media/ . Because nobody has pushed it into the user space library yet. Once it is in the user space library and the V4L2 stuff is in the pwc code it makes sense to obsolete it from pwc. It isn't about where the decompressor is, it is about how we get there. Alan --- 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=6595alloc_id=14396op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Security and USB.
On Sul, 2005-01-23 at 05:43, Greg KH wrote: But as you already have physical access to the machine, it's quite easy to comprimise it in other ways, so hostile USB devices aren't really a pressing issue. This is becoming the most worn out security myth on the planet. Physical access in many environments is very different to the ability to do harm. In many office environments you can't take the PC apart without people noticing while nobody would consider a USB key hostile. The university threat model is also based on my experience on physical access being non-compromising because the systems are locked shut and fastened to alarm cables. They have BIOS passwords and forced boot orders. Hostile USB devices are a threat, the rest is just sloppy Windows world excuses. That said everyone (not just Greg) needs to be looking for USB driver code that does trust the messages from the driver and *fixing* it. The big danger is probably not so much DoS cases which are a nuisance certainly but stuff that trusts device provided information for things like buffer sizes or knows devices won't provide too much data. Any kiddie with a cheap USB dev kit can knock out an attack tool nowdays. Alan (Be glad you don't have firewire... 8)) --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Partition and removable devices
On Sul, 2005-01-09 at 15:41, Andries Brouwer wrote: Windows can handle removable usb devices with and without partition table. It is quite common for Compact flash and Smart Media cards to have a partition table. Older Windows (98 etc) ignores CF cards without a partition table in my experience. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6: hcd.c: timer not removed?
On Llu, 2005-01-10 at 10:42, Matthias Urlichs wrote: hcd = container_of (bus, struct usb_hcd, self); + if(hcd-rh_timer.data) + del_timer_sync (hcd-rh_timer); kfree(hcd); If init_timer has ever been called then you can just use del_timer_sync and it does the right thing on any time (it has to since the timer could expire as you delete it). If not then timer.data isn't safe either. I think you can thus lose that if --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: changes to tty subsystem
On Llu, 2005-01-10 at 11:03, Oliver Neukum wrote: Hi, you have done some fixes to the tty layer, haven't you? Is there anything that user of the layer need to change? I am getting reports of modems working only once and not hanging up correctly. The original 2.6.9 patches had a bug in some configurations where pppd didn't hang up. Fixed in 2.6.9-ac and in 2.6.10. The only real change for a line discipline is that there is a hangup callback and the close callback is only done at real close time now. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB problems with SIS 530/5595 board
On Maw, 2005-01-04 at 19:44, David Brownell wrote: If 2.6.10 doesn't work, then it'd be worth sorting out what the problem is. There's no fundamental reason that old Socket7 chipset shouldn't work just fine with Linux. I've got a sis530 in the junk pile here if it can be usefully used. Also the chipset docs although SiS docs often don't include good errata info. Alan --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB problems with SIS 530/5595 board
This I noticed in the docs: The support is for USB 1.0 not 1.1 OHCI 1.0 for USB 1.0 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH as440] UHCI: Add volatile to declarations
On Llu, 2005-01-03 at 18:31, Pete Zaitcev wrote: Fist is SMP: volatile does nothing to help serialize accesses, although I can see that in perhaps in this case it's not an issue. The second is portability: on a few CPUs special instructions are necessary for serializations, which are provided by memory barriers. I would suggest adding barriers explicitly. It also causes abominably bad code generation compared to explicit barriers. Consider volatile the wrong solution. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH as440] UHCI: Add volatile to declarations
On Llu, 2005-01-03 at 19:50, Alan Stern wrote: Going in and inserting barriers by hand is a painstaking and error-prone process, particularly when the code changes in the future. By adding a single volatile, I can make the compiler do all that work for me, with no errors. In David's words, it's a tradeoff. As the maintainer, I decided to go in favor of simplicity and ease-of-maintenance. Thats unfortunate because we know from years of history its always been the wrong decision, that older gcc gets volatile wrong and that processor speculation which is not covered by volatile keywords still eats you alive on PPC platforms. Your choice as maintainer however if anyone would like to send alternate barrier based patches for 2.6.10-ac I'd appreciate it. Alan --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH as440] UHCI: Add volatile to declarations
On Llu, 2005-01-03 at 22:05, Alan Stern wrote: On Mon, 3 Jan 2005, Alan Cox wrote: Alan, I respect your judgement and your advice. If after looking more closely at this you still think the code should be changed to use barriers instead, I will do it. But first you should read my reply to Pete, and you should see how the driver is affected. You will be hard-pressed to find any spots where the volatile causes abominable code generation. In terms of bad code, it will make uhci_show_qh keep reloading from memory for each UHCI_ foo that it looks at. uhci_insert_tds_in_qh cases the objects so will end up using non volatile anyway. uhci-hcd.c seems not to be too affected None of this helps much when you are worried about races agains the host controller however because the processors will speculate and volatile is only a compile ordering tool. Even if volatile forces the ordering of writes in the assembler, the processors like the PPC ones will then change their minds unless you coax them nicely with rmb/wmb and friends. Another little nasty is that operations like*x |= 1 on a volatile will still generate reg = *x reg |= 1 *x = reg on many processors, which is why we ended up with functionality like set_bit() Dave asked about speculation. The kind of things the processors will do with main memory references (and sometimes other references but not readl/writel type) is to issue them out of order, or just in case. Even with volatiles everywhere code like code = *v; if(*a == 1) ret = *b; else ret = *c; can come out of the processor ordered as read *b read *c read *a read *v When you use the barrier functions the kernel provides either explicitly, or implicitly in the spinlock functions, those barriers are true CPU level barriers (rmb/wmb). volatile is dont cache, the barriers are -ordering-, and in almost all cases what you care about is ordering as in the example compilation problem posted. I make the comments based on several experiences where we added volatile and then eventually ended up fixing it properly. I certainly can't guarantee I am right I'm just voicing and opinion. Alan --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Why is USB still a problem?
On Mer, 2004-12-29 at 05:26, Garth Kay-Hards wrote: Now when it comes to the USB devices the system dosen't even allow me to try and choose a modem or scanner from a list. In fact they system doesn't show USB devices in hardware setup (why?). Surely I don't have to go out and Ask your distro vendor. They should at least be shipping tools like lsusb and Greg KH's hotplug based autoconfiguration nowdays. It's not entirely perfect yet (eg Fedora Core will find USB printer and CD but not always disks without help). USB is also particularly problematic because so few vendors follow standards unlike say bluetooth where gnome-bluetooth essentially just works because the phones all speak the same protocols. purchace a modem that's Linux compatible - as someone here suggested to me. The modem is a common Creative Modem Blaster DE5670. That's not what the PC should be about. Ask Creative to provide drivers or docs. Alan --- 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://productguide.itmanagersjournal.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ep0 timeout followed by device removal, ep0 timeout continues
On Gwe, 2004-10-22 at 16:15, Kyle Harris wrote: I have a condition where a certain usbdrive occasionally fails with ep0 timeout. If I remove the device when this happens, it appears the core does not detect its removal. I have verified that the hcd properly sets the change bits for the port, but it seems that the hub_status is not checked during this time. Is there something else the hcd should do in this situation? Does lsusb also hang after this - if so I've seen this in 2.6.8 but it seems fixed in 2.6.9 --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: new locking in change_termios breaks USB serial drivers
On Gwe, 2004-10-01 at 19:14, Al Borchers wrote: * The tty layer could use a semaphore so the USB serial set_termios could sleep until the new termios settings have taken effect before returning. This seems to be the right choice and is the change I will implement. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: new locking in change_termios breaks USB serial drivers
On Gwe, 2004-10-01 at 11:40, Al Borchers wrote: Unfortunately, many USB serial drivers' set_termios functions send an urb to change the termios settings and sleep waiting for it to complete. I just looked quickly, but it seems belkin_sa.c, digi_acceleport.c, ftdi_sio.c, io_ti.c, kl5usb105.c, mct_u232.c, pl2303.c, and whiteheat.c all sleep in their set_termios functions. If this locking in change_termios() stays, we are going to have to fix set_termios in all of these drivers. I am updating io_ti.c right now. How much of a problem is this, would it make more sense to make the termios locking also include a semaphore to serialize driver side events and not the spin lock ? We need some kind of locking there otherwise multiple parallel termios setters resulting in truely strange occurences because driver authors don't think about 64 parallel executions of -change_termios() I can switch the lock around if you want. Alan --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 3/3] cypress_m8: add usb-serial driver 'cypress_m8' to kernel tree
On Gwe, 2004-10-01 at 01:02, Lonnie Mendez wrote: This patch adds the cypress_m8 usb-serial driver for the Delorme Earthmate usb gps and the Cypress hid-com rs232 adapter to the kernel tree. Signed-off-by: Lonnie Mendez [EMAIL PROTECTED] Please don't add this yet. Firstly fix the fact the bogus call to set_ldisc in the code. Secondly mask_to_rate is wrong. The mask to rate conversions depend upon the platform (long story of compatibility) and you should use the tty layer one. The ioctl todo's for termios also need doing. Having TCGETS as a no-op does not make the code ready for merging. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch 3/3] cypress_m8: add usb-serial driver 'cypress_m8' to kernel tree
On Gwe, 2004-10-01 at 16:48, Lonnie Mendez wrote: look at pl2303_set_termios, it's almost the exact same setup except I exported some of the code into another function 'cypress_serial_control'. I do not see any platform dependent code here in regards to the line setting code. If that is all you guys can see wrong, I will resubmit it. I'm happy to take a look at a newer version. I'm currently trying to document the tty layer and clean up the interfaces. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: new locking in change_termios breaks USB serial drivers
On Gwe, 2004-10-01 at 17:24, Al Borchers wrote: Its a design decision for the tty layer. You should choose whatever is best there and the drivers will have to adapt. From a tty layer I don't think there is a motivation to enforce no sleep. Hopefully nobody has a reason to need to fiddle with termios data in their IRQ handlers ? To correctly support TCSETAW/TCSETSW the USB serial drivers would have to have two different versions of set_termios--a non sleeping one to be called Providing the driver isnt sticking its nose into -ioctl the tty layer core already correctly handles TCSETAW for you because it uses tty_wait_until_sent before issuing the change. You don't have to deal with that providing you've implemented driver-chars_in_buffer, and if neccessary -wait_until_sent. In a waiting case the driver will get -chars_in_buffer until it returns zero -wait_until_sent -change_termios which serializes with respect to the one writer. If you have a writer during a termios change by another well tough luck, you lose and I've no intention of changing that behaviour unless someone cites a standard requiring it. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usbserial.c patch for 2.4.21-20 kernels
On Maw, 2004-09-28 at 16:46, Sam King wrote: serial_unthrottle is not an issue because it is called as the result of system calls, where as serial_throttle is called when the tty driver buffer is full. As we have seen, calls to serial_throttle can occur from an interrupt handler when the driver is receiving too much new data. This can make the semaphore down function call inside serial_throttle panic. This is not guaranteed or written down as a rule anywhere but it looks ok for 2.4.x. For 2.6 I'm still trying to fix the locking and actually document rules. Alan --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] How to handle string descriptor request from usb-uhci
On Maw, 2004-09-07 at 21:48, Toralf Lund wrote: Actually, our company name is strictly speaking Latin, but I don't think it would be right to say that in the USB descriptors. Just like you probably wouldn't encode your first name as Celtic (which I think it originally is) Probably Gaelic yes. As to special characters, whether a special character means a word isn't in that language is more complex and depends on the language I'm afraid. More seriously it would be good if vendors remembered - Not everyone has all full unicode font set so while linear-B may be leet its not going to make people happy - A lot of disabled screen reading tools in the west tend to come apart if you got much beyond ascii so you may fail S.508 considerations. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] RE: [PATCH] Early USB handoff
On Iau, 2004-09-02 at 20:03, Aleksey Gorelov wrote: Basically, in a case of legacy free BIOS, HC is not in SMM mode, and USB IRQ is routed to PCI IRQ line and generates interrupts. When this IRQ is enabled in PIC (by driver that starts before HC driver), system is flooded with interrupts. The BIOS should not be leaving the device generating interrupts surely ? If that IRQ line ends up shared we are in trouble at boot time. One solution is to reset HC, but it takes some time (at least 50ms). I agree that it might duplicate SOME code in HC driver, but HC init executes too late. Well, if handoff has been done early, it might not be necessary to do the same in HC driver. We don't always want to hand off. Some setups only work in USB legacy mode because of other bugs. Thats why the SMM fixup I did for E750x is triggered in specific cases. We can do such things with DMI table blacklists easily enough. My E750x fix already duplicates some of the hand off code so we are going to need it anyway and if there are more reasons for needing it then so be it. I happened to only need to fix UHCI thats all. Alan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Summarizing the PWC driver questions/answers
On Sad, 2004-08-28 at 00:13, Oliver Neukum wrote: Keeping drivers against the wishes of the authors in the tree would be very troubling for the future. I can assure you that no maintainer will lightly pull a driver in this way. Then the kernel community is no longer fit to use my code. So you should remove everything I've written from Linus kernel too. I'll maintain my own kernel. Oh gosh, look I've just crippled Linus tree and stolen his project. Thats *WHY* you can't just rip drivers out. A license was granted, for ever. You can certainly remove him from maintainers, and if he insists from the author credits. Alan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: pwc+pwcx is not illegal
On Gwe, 2004-08-27 at 20:29, Linus Torvalds wrote: So stop whining about it. The driver got removed because the author asked for it. Please put it back, minus the hooks so the rest of the world can use it. If not please remove every line of code I've even written because I don't like the new attitude .. so ner.. Point made ? We can't go around throwing out drivers because the author had a tantrum. Its also trivial to move the decompressor to user space where it should be anyway. Similarly the driver is useful without the binary stuff. Or do we need a -ac tree again where this time -ac is added camera ;) Alan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: pwc+pwcx is not illegal
On Sul, 2004-08-29 at 17:33, Nemosoft Unv. wrote: That's one of the reasons I requested PWC to be removed. For me, it's also a matter of quality: what good is a half-baked driver in the kernel when you need to patch it first to get it working fully again? I don't want my name attached to that. It works very well for some users without that code. The raw pass through for the compressed bitstreams solved the problems for the rest. You appear to be seeking to hurt your userbase for your own ends. Thats not pleasant behaviour. I can more than understand take my name off it, make it clear its nothing to do with me. Its also trivial to move the decompressor to user space where it should be anyway. *sigh* As I have been saying a 100 times before, it is illogical, cumbersome for both users and developers, and will probably take a very long time to adopt (notwithstanding V4L2 [*]). Video4linux has -always- specified decompressors in user space. This was pointed out ages ago. V4L2 rationalised it even more clearly. *IF* there was a commonly accepted video middle-layer, this would not pose much of a problem. But there is no such thing yet. (maybe that's something for a 2.7 kernel...) No its for userspace. Just add it to the relevant video frameworks. Seriously, this probably would not have happened if, back in 2001, the driver was rejected on the basis of this hook (you were there, Alan...) I never made a secret of it, it has been in the driver from day 1 and its purpose was clearly spelled out. If it had been rejected, I would probably have just switched to '3rd party module' mode and maintained it outside the kernel indefinetely. I would not have liked it, but it would have been acceptable. Back in 2001 I was saying that this was broken and it belonged in user space. of thing in the kernel. However, since we're a bit late to react, we'll leave it in the 2.4 and 2.6 series, but versions beyond that (2.7-devel, etc) will not have PWC included in this form. In the mean time, we're asking you to think of a solution. Chances are the situation would have been fully resolved before that (and I mean fully *hint*). There isn't a plan to have a 2.7 development tree but to do gradual development until something major comes up. That makes the suggestion rather more tricky - as does the legal question. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB shared interrupt problem
On Gwe, 2004-08-06 at 21:42, Pete Zaitcev wrote: I have a patch which prevents SMM BIOS from doing this to us by requesting unconditional handoff (it comes from Vojtech @SuSE, modified by John Stulz from IBM for 2.4). However, if you have a normal BIOS doing this, I'm a little lost as to what to do. It can still honor the handoff, if you're lucky. In SMM mode the USB controller isn't connected to the PCI IRQ line. That is one thing that is done in the changeover. It also seems to be causing problems with EHCI hand over on NVidia boards still. BTW the patch wants extending by someone to cover EHCI - modern boards are doing EHCI USB legacy now. Alan --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Driver for the Siemens ID Mouse
On Mer, 2004-07-28 at 19:39, Oliver Neukum wrote: // reset the buffer position dev-buffer_pos = 0; If you are allowing multiple openers you cannot reset the buffer. And run it through indent. I don't see how you can do this with a single opener since it can then be threaded and issue multiple I/O's in parallel. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: RE : MPC5200Lite PCI IRQ
On Sad, 2004-06-26 at 15:24, David Brownell wrote: Is there a designated no IRQ assigned code? There should be one ... that's why such code gets cut/pasted. Unless pci_enable_device() is (now) guaranteed to fail if the device has no IRQ assignment? There are a lot of drivers that assume 0 means no IRQ, including some big x86 non-PC systems. Remember however that dev-irq is an OS private cookie. In the x86 case for example we add 16 to APIC directed interrupts both to split IRQs out and to avoid this problem. So if your board has an IRQ 0 and it is a problem - just change your numbering scheme. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Patch for UHCI driver (from kernel 2.6.6).
On Maw, 2004-06-15 at 10:08, Nicolas DET wrote:
For this specific case, the interrupt handler should manage it:
if ( (!(status ~USBSTS_HCH)) /* shared interrupt, not mine */
|| (!uhci-IntEnableReg_SW) )
{
retval = IRQ_NONE;
goto end;
}
uhci-IntEnableReg_SW is the software view of the Interrupt Enable
register of our UHCI chipset.
It makes me nervous. The first thing I see is the question about
ordering between posted writes to the IntEnable reg in PCI space and the
software register. The second thing is returning IRQ_NONE causing the
screaming interrupt warning.
I'm not saying you are wrong, its the kind of code that I really really
would never write unless it had huge payback.
So if the interrupt arrives between stop_interrupt and spin_lock, the
handler will no be taken because IntEnableReg_SW would be 0 (set by
stop_interrupt) and the spin_lock would not be executed.
You do hang in the IRQ handler in this case until the drop of the IRQ
reaches the far end of the link because it is level triggered.
Alan
---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb_bulk_msg and data pointer
On Sad, 2004-06-12 at 19:33, Margit Schubert-While wrote: Now the curiousity; if we use a pointer to the data area as returned from request_firmware, it doesn't work. If, however, we use the stack (or a kmalloc'ed area) and copy over and pass the stack (or km'ed area) address, then it works. Only thing I could find is that request_firmware allocates the data area using vmalloc. Why is this a problem ? vmalloc is scatter gather virtual addressed data. It isnt DMAable. kmalloc space is linear and DMAable generally as (on some platforms only) is the stack. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Problem with lots of junk emails on this list.
On Llu, 2004-06-14 at 04:47, Trent Whaley wrote: It's not just you. By my count there have been 400+ of them in the last two days. They've been appearing (mostly) in batches of 35-40 and It looks like someone's joe-jobbing [EMAIL PROTECTED] it's just plain nasty. Some random spambot has picked it for a source address, unfortunately the list owner hasn't set things like bounce messages to be blocked in the majordomo configuration for the list. Easily fixed once the list admin is awake. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
