Re: [patch]Re: [rfc]io performed by mos7720 upon close()
Am Donnerstag, 17. Januar 2008 01:42:30 schrieb Greg KH:
> On Wed, Jan 16, 2008 at 05:18:52PM +0100, Oliver Neukum wrote:
> > Am Donnerstag, 20. Dezember 2007 16:51:59 schrieb Alan Stern:
> > > On Thu, 20 Dec 2007, Oliver Neukum wrote:
> > >
> > > > @@ -1080,20 +1081,22 @@ void usb_serial_disconnect(struct usb_in
> > > > usb_serial_console_disconnect(serial);
> > > > dbg ("%s", __FUNCTION__);
> > > >
> > > > + mutex_lock(&serial->disc_mutex);
> > > > usb_set_intfdata (interface, NULL);
> > > > - if (serial) {
> > > > - for (i = 0; i < serial->num_ports; ++i) {
> > > > - port = serial->port[i];
> > > > - if (port) {
> > > > - if (port->tty)
> > > > - tty_hangup(port->tty);
> > > > - kill_traffic(port);
> > > > - }
> > > > + /* must use extra flag, as intfdata can be reset */
> > > > + serial->disconnected = 1;
> > >
> > > This comment is misleading. It implies there is a possibility you
> > > actually could check for disconnects by looking at the value of
> > > usb_get_intfdata(), but that's completely wrong. There are about 13
> > > places in various serial drivers where this mistake is made; they all
> > > need to be fixed.
> > >
> > > Don't you also have to check the disconnect flag in serial_close()
> > > before calling usb_autopm_put_interface()?
> >
> > Where is that?
> >
> > This fixes a problem where the mos7720 driver will make io to a device from
> > which it has been logically disconnected. It does so by introducing a flag
> > by
> > which the generic usb serial code can signal the subdrivers their
> > disconnection and appropriate locking.
> >
> > Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
> >
> > I'd call this 2.6.25 material.
>
> But does it really "solve" anything? Sure, it decreases the chance of a
> race, but it can still happen (disconnect and close at the same time,
> close starts to send messages before disconnect changes theserial->disc_mutex
> "disconnected" flag).
>
> Or am I missing something else here?
Both close() and disconnect() take serial->disc_mutex
Either close() is first, then disconnect() must wait for close(). As long
as disconnect() doesn't return close() may legitimately write to the device,
or disconnect() comes first and close() will see the flag and not write.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: USB gadget serial on PXA-270
Hy, > Were you getting such messages from the kernel? "dmesg" > would show them if you were. Sorry, i forgot to mention that i included some "extended" printk's by myself. > But again: if you're not already getting those warnings, > don't bother looking since that's not the problem. I get no messages from the "normal" g_serial module. I'm using the PuTTYtel (version. 0.6 on Windows XP SP2) and the error message after plugin the USB cable is: "unable to open connection to COM4. Unable to configure serial port." (i configured PuTTYtel with speed: 115200 and connection type: serial) Sorry, if i bore you, just to get sure there is no "methodic" error: 0. configure and compile hardware udc driver and gadget serial module 1. "mknod /dev/ttygserial c 127 0" 2. modprobe g_serial use_acm=1 3. plugin USB client cable 3.a following printouts on Client were created: -- START PRINT OUT -- gs_disconnect: Gadget Serial disconnect gs_disconnect: Gadget Serial disconnect gs_disconnect: Gadget Serial disconnect gs_set_config: Gadget Serial configured, full speed CDC-ACM config -- END PRINT OUT -- 3.b On Host (Windows XP SP-2) in the device manager is a comport COM4 created with the name "Gadget Serial" (Until now, all seems to be ok) 4. start PuTTYtel and try to open the COM4 (115200,8,1,None,no flow control) (at least the speed configuration has no effect) 5. after a few seconds the error message described above is shown. (Steps 0-3 are documented in the gadget_serial.txt) Some (perhaps silly) questions: 1. to "attach" a terminal programm (like getty) to that resulting device i have to do "/sbin/getty -L 115200 /dev/ttygserial"? 2. If i haven't done "attaching terminal programm" may be that the errror (handling error by myself)? 3. The "extern int net2280_set_fifo_mode(...)" statement on line 251 (serial.c) should be adapted to the "real" hardware or replaced by the appropriate function of the *_udc driver? As a try to compare i used a linux (Suse 10.1) as host. I unpluged the usb cable (no target system restart) and attached the cable to a linux host. The resulting dmesg of the host (!): -- START DMESG HOST OUTPUT -- usb 3-1: new full speed USB device using uhci_hcd and address 2 usb 3-1: new device found, idVendor=0525, idProcduct=a4a7 usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1: Product: Gadget Serial usb 3-1: Manufacturer: Linux 2.6.22-default with pxa27x_udc usb 3-1: SerialNumber: 0 usb 3-1: configuration #2 chosen from 1 choice drivers/usb/class/cdc-acm.c: This device cannot do calls on its own. It is no modem. cdc_acm 3-1:2.0: ttyACM0: USB ACM device usbcore: registred new driver cdc_acm drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters -- END DMESG HOST OUTPUT -- On the target side i executed a 'cat /dev/ttygserial'. Afterwards on the host side i executed a 'echo "1" > /dev/ttyACM0' As expected a "1" appeares on the target side. But the other way round the "1" didn't appear. After attaching a getty to the /dev/ttygserial (descibed above) and starting a configured minicom on the linux host i'm able to login on the target platform. After a "exit" (exit off the login on the target platform) the "attached" getty terminates. What is the "correct" way to attach the getty "permanently" to the ttygserial device? (entry in the inittab? But on the time inittab excecutes the ttygserial is not present to the system). Conclusions: 1. pxa27x_udc seems to be ok 2. gadget serial in ACM mode works on linux hosts => Windows seems to do some none standard procedures (?) - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: USB gadget serial on PXA-270
Hy, > The following thread is quite good. The author is quite good > at USB and he thinks that usbser.sys is weird. > http://www.cygnal.org/ubb/Forum9/HTML/000945.html Thanks for your hint, i'll check it. > Still I will think "unable to open COM Port" error may not be > due to the device at all. The reason may well be that there > is another program is using the com port. I think exclude that there is another programm using that com port > By the way, try to use other terminal program. Hyperterminal > is know to be problematic with USB serial. Realterm is a better one. I use PuTTYtel (version 0.6) but will have a look at the Realterm. Regards, Aurel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add documentation for USB suspend statistics.
This documents two newly created files: /sys/bus/usb/device/.../power/connected_duration /sys/bus/usb/device/.../power/active_duration Documentation was placed in Documentation/ABI/testing, since that's where the documentation is for the other USB sysfs power files. Signed-off-by: Sarah Sharp <[EMAIL PROTECTED]> --- Documentation/ABI/testing/sysfs-bus-usb | 33 +++ 1 files changed, 33 insertions(+), 0 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 9734577..23e5231 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -52,3 +52,36 @@ Description: facility is inherently dangerous, it is disabled by default for all devices except hubs. For more information, see Documentation/usb/persist.txt. + +What: /sys/bus/usb/device/.../power/connected_duration +Date: January 2008 +KernelVersion: 2.6.25 +Contact: Sarah Sharp <[EMAIL PROTECTED]> +Description: + If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file + is present. When read, it returns the total time (in jiffies) + that the USB device has been connected to the machine. This + file is read-only. +Users: + PowerTOP <[EMAIL PROTECTED]> + http://www.lesswatts.org/projects/powertop/ + +What: /sys/bus/usb/device/.../power/active_duration +Date: January 2008 +KernelVersion: 2.6.25 +Contact: Sarah Sharp <[EMAIL PROTECTED]> +Description: + If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file + is present. When read, it returns the total time (in jiffies) + that the USB device has been active, i.e. not in a suspended + state. This file is read-only. + + Tools can use this file and the connected_duration file to + compute the percentage of time that a device has been active. + For example, + echo $((100 * `cat active_duration` / `cat connected_duration`)) + will give an integer percentage. Note that this does not + account for counter wrap. +Users: + PowerTOP <[EMAIL PROTECTED]> + http://www.lesswatts.org/projects/powertop/ -- 1.5.3.4 - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb-serial: Sierra driver - add devices and update dtr
On Mon, Jan 14, 2008 at 09:21:32AM -0800, Kevin Lloyd wrote: > > Hm, no, the intrusion into the driver is just too much this late in > the > > release cycle to allow this. > > > > Now I will be glad to only add the new device ids for the devices that > > do not rely on the new changes right now, but that's it. > > > > So, right now I have a separate patch split out of your original one > > that is below. Should I modify it and not include some of these > device > > ids right now? You mention 0023, is that the only one I should remove > > from this patch? > > Correct, the 0x0023 is the only newly added device that requires the new > features. Does that mean things will not work for this device if it is added to the device table, without the code updates? And is this device even public yet? > When do you expect the other changes will be propagated to the kernel? > Would it be in a 2.6.24.x point release or will they have to wait until > 2.6.25? They will have to wait until 2.6.25, they are too big to go into 2.6.24 (we are in severe bug-fix mode only right now for .24). thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb-serial: ftdi driver- add support for optical probe device
This patch is for the 2.6.24-rc8 kernel.
Added support for the Elster Unicom III Optical Probe.
The device ID has already been added to the usb.ids file.
Signed-off-by: Ed Beroset <[EMAIL PROTECTED]>
---
diff -aur --exclude-from=a/.gitignore a/drivers/usb/serial/ftdi_sio.c
b/drivers/usb/serial/ftdi_sio.c
--- a/drivers/usb/serial/ftdi_sio.c 2008-01-16 10:03:24.0 -0500
+++ b/drivers/usb/serial/ftdi_sio.c 2008-01-16 10:59:22.0 -0500
@@ -17,6 +17,10 @@
* See http://ftdi-usb-sio.sourceforge.net for upto date testing info
* and extra documentation
*
+ * (16/Jan/2007) Ed Beroset
+ * Added PID for Elster Unicom III Optical Probe
+ * see http://www.elsterelectricity.com/ for product description
+ *
* (21/Jul/2004) Ian Abbott
* Incorporated Steven Turner's code to add support for the
FT2232C chip.
* The prelimilary port to the 2.6 kernel was by Rus V.
Brushkoff. I have
@@ -571,6 +575,7 @@
{ USB_DEVICE(TML_VID, TML_USB_SERIAL_PID) },
{ USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID),
.driver_info = (kernel_ulong_t)&ftdi_olimex_quirk },
+ { USB_DEVICE(FTDI_VID, FTDI_ELSTER_UNICOM_PID) },
{ },/* Optional parameter entry */
{ } /* Terminating entry */
};
diff -aur --exclude-from=a/.gitignore a/drivers/usb/serial/ftdi_sio.h
b/drivers/usb/serial/ftdi_sio.h
--- a/drivers/usb/serial/ftdi_sio.h 2008-01-16 10:03:24.0 -0500
+++ b/drivers/usb/serial/ftdi_sio.h 2008-01-16 11:01:44.0 -0500
@@ -534,6 +534,8 @@
#define OLIMEX_VID 0x15BA
#define OLIMEX_ARM_USB_OCD_PID 0x0003
+/* www.elsterelectricity.com Elster Unicom III Optical Probe */
+#define FTDI_ELSTER_UNICOM_PID 0xE700 /* Product Id */
/*
* The Mobility Lab (TML)
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb-serial: Sierra driver - add devices and update dtr
> > Correct, the 0x0023 is the only newly added device that requires the new > > features. > > Does that mean things will not work for this device if it is added to > the device table, without the code updates? Adding the device will not break the driver (assuming you remove the tag). > And is this device even public yet? No, but we are trying to add native support for devices into kernels well before they are released in an effort give better native support to end-users. > > When do you expect the other changes will be propagated to the kernel? > > Would it be in a 2.6.24.x point release or will they have to wait until > > 2.6.25? > > They will have to wait until 2.6.25, they are too big to go into 2.6.24 > (we are in severe bug-fix mode only right now for .24). Darn. Thanks, -Kevin - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
USB device not listed in database
I have a printer device that is not listed in usb database: T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 18 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=10ce ProdID=000e Rev= 0.01 S: Manufacturer=SHINKO S: Product=CHC-S2145 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=usblp E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms It's a Dye Sublimation printer. I build a driver using libusb but it conflicts with usblp. Now I'm using guten-print to build a driver for cups, but cups usb backend not find the device ID, and when I plug the printer /dev/usb/lp0 device is correctly created. cups code fails when it calls to: ioctl(fd, LPIOC_GET_DEVICE_ID(device_id_size), device_id) causing : Input/output error I'm not shure if it's a cups problem or a kernel problem. With my libusb code the printer works fine, so the problem is not on the hardware... Can you help please ? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB device not listed in database
On Fri, Jan 18, 2008 at 01:57:31AM +0100, Jordi Fern?ndez wrote: > > I have a printer device that is not listed in usb database: What "usb database"? There is no such thing in the kernel. > T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 18 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=10ce ProdID=000e Rev= 0.01 > S: Manufacturer=SHINKO > S: Product=CHC-S2145 > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 2 Cls=07(print) Sub=01 Prot=02 Driver=usblp > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > It's a Dye Sublimation printer. I build a driver using libusb but it > conflicts > with usblp. Now I'm using guten-print to build a driver for cups, but cups > usb backend not find the device ID, and when I plug the printer /dev/usb/lp0 > device is correctly created. > cups code fails when it calls to: > ioctl(fd, LPIOC_GET_DEVICE_ID(device_id_size), device_id) > causing : Input/output error > > I'm not shure if it's a cups problem or a kernel problem. Sounds like a cups issue. Have you asked those developers? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
