Am Donnerstag, 22. März 2007 18:07 schrieb Alan Stern:
On Thu, 22 Mar 2007, Oliver Neukum wrote:
Hi,
I'd like to make the following change to autosuspend:
--- linux-2.6.21-rc4-git6/include/linux/usb.h.alt 2007-03-22
14:26:26.0 +0100
+++
Hi,
I got a bug report about a device failing if EHCI is loaded shortly
after OHCI had been loaded. The device stalls. This seems to violate
the spec. Is there a reason not to clear the halt?
Regards
Oliver
usb 2-6.1.4: khubd timed out on ep0in len=0/255
usb 2-6.1.4:
Hi,
this fixes a small race in visor_write.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/usb/serial/visor.c2007-03-23 11:43:28.0 +0100
+++ b/drivers/usb/serial/visor.c2007-03-23 11:55:06.0 +0100
@@
Hi,
this has the same race as the visor driver. The counter must be incremented
under the lock it is checked under.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/usb/serial/ftdi_sio.c 2007-03-23 14:20:14.0 +0100
+++
Hi,
the correct error code for an unknown ioctl is ENOTTY.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/usb/input/hiddev.c2007-03-23 16:36:28.0 +0100
+++ b/drivers/usb/input/hiddev.c2007-03-23 16:36:32.0
On Fri, 23 Mar 2007, Oliver Neukum wrote:
the correct error code for an unknown ioctl is ENOTTY.
(as already written in private mail conversation)
Hi Oliver,
are you sure about this? Looking at what POSIX states:
[EINVAL]
The request or arg argument is not valid for this device.
On Fri, 23 Mar 2007, Oliver Neukum wrote:
Can you explain in more detail what you want to accomplish here? I'm
still puzzled. Are you trying to avoid letting the timer expire
repeatedly while the device is in use for a prolonged time?
It was my understanding that we are still working
On Fri, 23 Mar 2007, Oliver Neukum wrote:
Hi,
I got a bug report about a device failing if EHCI is loaded shortly
after OHCI had been loaded. The device stalls. This seems to violate
the spec. Is there a reason not to clear the halt?
Regards
Oliver
usb 2-6.1.4:
On Friday 23 March 2007 5:26 am, Pandita, Vikram wrote:
Hi
I am testing HS USB HOST controller of OMAP2430 (MUSBHDRC) with
Netchip2280 device using usbtest. When I run the test.sh control test on
the OMAP Host, the test 14 fails randomly after some iterations with
error no -32.
Does
Hi,
Since last December me and Oliver are trying to
fix a number of problems in usb-serial.c.
Most of them happen when devices are plugged
and unplugged and files are opened and closed
in various orders.
usb-serial.c registers new tty ports by calling
device_register from usb_serial_probe
On Thu, Mar 22, 2007 at 10:46:53PM +0100, Tino Keitel wrote:
On Thu, Mar 22, 2007 at 14:29:11 -0700, David Brownell wrote:
On Thursday 22 March 2007 12:54 pm, Tino Keitel wrote:
On Thu, Mar 22, 2007 at 15:40:40 -0400, Alan Stern wrote:
_Something_ is generating those
Hi,
Am Freitag, 23. März 2007 20:36 schrieb John:
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
What about devices that have serial numbers? Wouldn't it at least
be a good idea to make their file usage persistant?
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
What about devices that have serial numbers?
Wouldn't it at least
be a good idea to make their file usage persistant?
I am not sure what you mean as
devices that have
Hi,
Am Freitag, 23. März 2007 20:58 schrieb John:
I am not sure what you mean as
devices that have serial numbers?
USB devices can include a unique serial number allowing even devices
of the same kind to be distinguished.
Thus you would know that exactly the same device has been plugged in.
Fix annoying build warning when CONFIG_USB_SERIAL_GENERIC is undefined.
drivers/usb/serial/generic.c:24: warning: `generic_probe' declared `static'
but never defined
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: g26/drivers/usb/serial/generic.c
On Friday 23 March 2007 9:11 am, Alan Stern wrote:
We don't clear the halt because the host is never supposed to clear halts
on ep0. If the halt is a protocol stall (the normal case) then the
device will clear it automatically when it receives the next SETUP packet.
If the halt is a
Fix annoying build warning:
drivers/usb/serial/ftdi_sio.c:890: warning: enumeration value `FT232RL' not
handled in switch
Also add logic to detect FT232R chips (version 6.00, usb 2.0 full speed),
so that case isn't completely useless. (NOTE: FT232RL and FT232RQ are
the same chip in different
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
That means the numbers x in ttyUSBx will almost never
be re-used. To me that sounds like something that will
break lots of userspace code.
What about devices
On Fri, Mar 23, 2007 at 12:36:11PM -0700, John wrote:
Here two solutions are possible:
1. Keep port range (ttyUSB0 and ttyUSB1 in this case)
reserved until all files are closed.
This is what the current code attempts to do.
But this means that if the same device is re-plugged,
it will be
On Fri, Mar 23, 2007 at 08:42:28PM +0100, Till Harbaum / Lists wrote:
Hi,
Am Freitag, 23. M?rz 2007 20:36 schrieb John:
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
What about devices that have serial numbers?
Those aren't serial numbers in the USB sense.
Consider any FT 232R device, which is assigned
one from the factory
I see. So, aparently, Till wanted to query
for the manufacturer's assigned serial number
and somehow remember which ttyUSBx port
we assigned to it and assign the same number
next
Am Freitag, 23. März 2007 21:18 schrieb David Brownell:
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
That means the numbers x in ttyUSBx will almost never
be re-used. To me that sounds like something that
I say #1 as I implemented it :)
If userspace still has the device node open, then we
need to keep the
number still in use.
OK, if this behavior is by design
(and it is hard to tell what is by design
and what is by accident when you look at a code
without any documentation),
then I will make
On Fri, Mar 23, 2007 at 01:35:44PM -0700, John wrote:
I say #1 as I implemented it :)
If userspace still has the device node open, then we
need to keep the
number still in use.
OK, if this behavior is by design
(and it is hard to tell what is by design
and what is by accident when
En/na Luca Olivetti ha escrit:
Hello,
I'd like to write a driver (or a userspace program) to interface with
this phone:
http://www.topcom.net/productfiche.php?i=432g=17
I contacted topcom but I doubt they'll reply with the required
information (besides, I doubt they are the real
--- Greg KH [EMAIL PROTECTED] wrote:
As for applications that foolishly use ttyUSB0 only,
well, they kind of deserve the breakage.
It is pretty trivial to work around that issue
with udev if they want to (and it's recommended
that they fix it that way...)
In this case somebody should
On Fri, Mar 23, 2007 at 07:18:50PM -0700, John wrote:
--- Greg KH [EMAIL PROTECTED] wrote:
As for applications that foolishly use ttyUSB0 only,
well, they kind of deserve the breakage.
It is pretty trivial to work around that issue
with udev if they want to (and it's recommended
On Fri, 23 Mar 2007, David Brownell wrote:
On Friday 23 March 2007 9:11 am, Alan Stern wrote:
We don't clear the halt because the host is never supposed to clear halts
on ep0. If the halt is a protocol stall (the normal case) then the
device will clear it automatically when it receives
On Fri, 23 Mar 2007, Greg KH wrote:
On Fri, Mar 23, 2007 at 12:36:11PM -0700, John wrote:
Here two solutions are possible:
1. Keep port range (ttyUSB0 and ttyUSB1 in this case)
reserved until all files are closed.
This is what the current code attempts to do.
But this means that if the
On Fri, Mar 23, 2007 at 11:30:16PM -0400, Alan Stern wrote:
On Fri, 23 Mar 2007, Greg KH wrote:
On Fri, Mar 23, 2007 at 12:36:11PM -0700, John wrote:
Here two solutions are possible:
1. Keep port range (ttyUSB0 and ttyUSB1 in this case)
reserved until all files are closed.
This is
On Fri, 23 Mar 2007, Greg KH wrote:
I don't buy the argument about needing to keep the number in use merely
because the device node is still open. Once the node has been
unregistered it is no longer visible to userspace. Only the existing open
file references can be used, and a new
On Fri, Mar 23, 2007 at 01:30:45PM -0700, John wrote:
Those aren't serial numbers in the USB sense.
Consider any FT 232R device, which is assigned
one from the factory
I see. So, aparently, Till wanted to query
for the manufacturer's assigned serial number
and somehow remember which
On Friday 23 March 2007 8:21 pm, Alan Stern wrote:
... no, that's a special case. Oddball devices that implement halt
status on ep0 must allow clear-halt requests for it too. See 8.5.3.4
and (especially) the end of 9.4.5 ...
Whoops! You're right. Sometimes those little details fade
33 matches
Mail list logo
