Re: [linux-usb-devel] OPEN Networks NT1 Plus II USB modem stopped working for 2.6.10 (cdc-acm.c)
Am Dienstag, 15. Februar 2005 06:25 schrieb Craig Keogh: > drivers/usb/class/cdc-acm.c: Entering acm_tty_write to write 1 bytes, > drivers/usb/class/cdc-acm.c: Entering acm_write_bulk with status 0 > drivers/usb/class/cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x2 len: 0x0 > result: 0 > drivers/usb/class/cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 > result: 0 > drivers/usb/class/cdc-acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 > result: 7 > drivers/usb/class/cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 > result: 0 > drivers/usb/class/cdc-acm.c: acm_ctrl_irq - urb shutting down with status: -2 Your modem is being disconnected. Please make sure you capture all debug output. Regards Oliver --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usbnet ax8817x recv performance patch
On Sun, 2005-02-13 at 14:07 -0700, Jamie Painter wrote: > I've observed poor receive performance in 100baseTx-FD mode from ax8817x > devices in all versions of usbnet.c. Half-duplex received performance > is actually better than full duplex. After some investigation, I found > that the MEDIUM_MODE wasn't being written, and this seems to affect > "Pause frame" full duplex flow control. > > The attached patch to 2.6.10, which sets the medium mode in an > ax8817x_reset function, doubled my full duplex performance (from ~45Mbps > to >90Mbps). > --Jamie The only issue that I see is that the usbnet_open() function (which calls the ax8817x_reset) is only called when the interface is brought from DOWN to UP state. If I initially connect to a 100FD switch, then unplug and plug into a 10HD hub, things may get squirrely. If I bring the device down and back up, things will reset and I'll be fine. Would it possibly be better to handle this within the interrupt handler that sees when link changes? That is an in_interrupt() call so you'd have to use the async read/write_cmd calls and implement an FSM to handle it. But there weren't too many calls so it shouldn't be a major issue. -- David Hollis <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [linux-usb-devel] usbnet ax8817x recv performance patch
David Hollis wrote: The only issue that I see is that the usbnet_open() function (which calls the ax8817x_reset) is only called when the interface is brought from DOWN to UP state. If I initially connect to a 100FD switch, then unplug and plug into a 10HD hub, things may get squirrely. If I bring the device down and back up, things will reset and I'll be fine. Would it possibly be better to handle this within the interrupt handler that sees when link changes? That is an in_interrupt() call so you'd have to use the async read/write_cmd calls and implement an FSM to handle it. But there weren't too many calls so it shouldn't be a major issue. Good point.I tried setting AX_MEDIUM_FULL_DUPLEX when in half duplex mode, and the interface still works, but performance is worse than when it's turned off. That's why I check the capabilities of the link partner to decide whether to set that bit. I'll take a look at dealing with the issue in an interrupt handler. --Jamie --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH 1/2][RESEND] ati_remote: Fix device/module removal.
On Mon, Feb 14, 2005 at 11:34:04PM +0200, Ville Syrjälä wrote: > Make ati_remote clean up properly when removing either the device or the > module. > > Signed-off-by: Ville Syrjala <[EMAIL PROTECTED]> Thanks; applied. -- Vojtech Pavlik SuSE Labs, SuSE CR --- 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_ide95&alloc_id396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH 2/2][RESEND] ati_remote: Change key assignments.
On Mon, Feb 14, 2005 at 11:34:07PM +0200, Ville Syrjälä wrote: > Some changes to ati_remote key assignments: > - Channel up/down keys are reversed on my ATI Remote Wonder. > - Use KEY_TV, KEY_DVD and KEY_OK where appropriate. > - Replace KEY_PLAYCD with KEY_PLAY. > > Signed-off-by: Ville Syrjala <[EMAIL PROTECTED]> > --- Thanks; applied. -- Vojtech Pavlik SuSE Labs, SuSE CR --- 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_ide95&alloc_id396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] state of usb-gadget.bkbits.net:8080/gadget-2.4 tree
David, I was wondering what the state of the usb-gadget.bkbits.net:8080/gadget-2.4 tree was. It appears that some changes got accepted into this tree (ARC EHCI TT host support). Is there a patch of this against some stock 2.4 tree around somewhere? thanks - kumar --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Problem with USB2 Host PCCard Zonet Zun2200
On Mon, 14 Feb 2005 19:59:05 +0100, narci22 <[EMAIL PROTECTED]> wrote: > > > I have a problem getting a USB2 PCCard to work under 2.6.11-rc3... > > > > Does this patch: > > > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110807703613198&w=2 > > > > improve things? > > no... not really... the system still hangs while trying to get the > correct device for the storage device > I just tried the new 2.6.11-rc4 kernel and the lookup doesn't exist anymore... but this time I got the following new error messages in the log: usb 4-1: new high speed USB device using ehci_hcd and address 2 usb 4-1: khubd timed out on ep0in usb 4-1: device descriptor read/64, error -110 usb 4-1: khubd timed out on ep0in usb 4-1: device descriptor read/64, error -110 Suggestions? fW --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unable to read after closing usb-serial device
On Tue, Feb 15, 2005 at 01:58:03PM +0800, Kharisma Esguerra wrote: > Hi, i'm having a problem with an application of mine that communicates with > a usb-serial device. Have you tried a newer kernel? 2.4.20 is a bit old now. thanks, greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] zd1201 wireless lan driver
Thanks for the tips Oliver.
Here is the third attempt.
Jeroen
Description: Driver for ZyDAS zd1201 based usb wireless adapters.
Signed-off-by: Jeroen Vreeken ([EMAIL PROTECTED])
diff -ruN linux-2.6.10.org/CREDITS linux-2.6.10-zd1201/CREDITS
--- linux-2.6.10.org/CREDITS 2004-12-24 22:35:23.0 +0100
+++ linux-2.6.10-zd1201/CREDITS 2005-02-15 21:50:01.0 +0100
@@ -3390,6 +3390,7 @@
E: [EMAIL PROTECTED]
W: http://www.chello.nl/~j.vreeken/
D: SE401 usb webcam driver
+D: ZD1201 usb wireless lan driver
S: Maastrichterweg 63
S: 5554 GG Valkenswaard
S: The Netherlands
diff -ruN linux-2.6.10.org/MAINTAINERS linux-2.6.10-zd1201/MAINTAINERS
--- linux-2.6.10.org/MAINTAINERS 2004-12-24 22:35:00.0 +0100
+++ linux-2.6.10-zd1201/MAINTAINERS 2005-02-15 21:50:01.0 +0100
@@ -2430,6 +2430,14 @@
W: http://www.linux-projects.org
S: Maintained
+USB ZD1201 DRIVER
+P: Jeroen Vreeken
+M: [EMAIL PROTECTED]
+L: linux-usb-users@lists.sourceforge.net
+L: linux-usb-devel@lists.sourceforge.net
+W: http://linux-lc100020.sourceforge.net
+S: Maintained
+
USER-MODE LINUX
P: Jeff Dike
M: [EMAIL PROTECTED]
diff -ruN linux-2.6.10.org/drivers/usb/net/Kconfig linux-2.6.10-zd1201/drivers/usb/net/Kconfig
--- linux-2.6.10.org/drivers/usb/net/Kconfig 2004-12-24 22:35:23.0 +0100
+++ linux-2.6.10-zd1201/drivers/usb/net/Kconfig 2005-02-15 21:49:24.0 +0100
@@ -287,4 +287,21 @@
This driver creates an interface named "ethX", where X depends on
what other networking devices you have in use.
+config USB_ZD1201
+ tristate "USB ZD1201 based Wireless device support"
+ depends on NET_RADIO
+ select FW_LOADER
+ ---help---
+ Say Y if you want to use wireless LAN adapters based on the ZyDAS
+ ZD1201 chip.
+
+ This driver makes the adapter appear as a normal Ethernet interface,
+ typically on wlan0.
+
+ The zd1201 device requires external firmware to be loaded.
+ This can be found at http://linux-lc100020.sourceforge.net/
+
+ To compile this driver as a module, choose M here: the
+ module will be called zd1201.
+
endmenu
diff -ruN linux-2.6.10.org/drivers/usb/net/Makefile linux-2.6.10-zd1201/drivers/usb/net/Makefile
--- linux-2.6.10.org/drivers/usb/net/Makefile 2004-12-24 22:33:49.0 +0100
+++ linux-2.6.10-zd1201/drivers/usb/net/Makefile 2005-02-15 21:49:24.0 +0100
@@ -7,3 +7,6 @@
obj-$(CONFIG_USB_PEGASUS) += pegasus.o
obj-$(CONFIG_USB_RTL8150) += rtl8150.o
obj-$(CONFIG_USB_USBNET) += usbnet.o
+obj-$(CONFIG_USB_ZD1201) += zd1201.o
+
+CFLAGS_zd1201.o = -Idrivers/net/wireless/
diff -ruN linux-2.6.10.org/drivers/usb/net/zd1201.c linux-2.6.10-zd1201/drivers/usb/net/zd1201.c
--- linux-2.6.10.org/drivers/usb/net/zd1201.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.10-zd1201/drivers/usb/net/zd1201.c 2005-02-15 21:49:25.0 +0100
@@ -0,0 +1,1896 @@
+/*
+ * Driver for ZyDAS zd1201 based wireless USB devices.
+ *
+ * Copyright (c) 2004, 2005 Jeroen Vreeken ([EMAIL PROTECTED])
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * Parts of this driver have been derived from a wlan-ng version
+ * modified by ZyDAS. They also made documentation available, thanks!
+ * Copyright (C) 1999 AbsoluteValue Systems, Inc. All Rights Reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "zd1201.h"
+
+static struct usb_device_id zd1201_table[] = {
+ {USB_DEVICE(0x0586, 0x3400)}, /* Peabird Wireless USB Adapter */
+ {USB_DEVICE(0x0ace, 0x1201)}, /* ZyDAS ZD1201 Wireless USB Adapter */
+ {USB_DEVICE(0x050d, 0x6051)}, /* Belkin F5D6051 usb adapter */
+ {USB_DEVICE(0x0db0, 0x6823)}, /* MSI UB11B usb adapter */
+ {}
+};
+
+static int ap = 0; /* Are we an AP or a normal station? */
+
+#define ZD1201_VERSION "0.15"
+
+MODULE_AUTHOR("Jeroen Vreeken <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Driver for ZyDAS ZD1201 based USB Wireless adapters");
+MODULE_VERSION(ZD1201_VERSION);
+MODULE_LICENSE("GPL");
+module_param(ap, int, 0);
+MODULE_PARM_DESC(ap, "If non-zero Access Point firmware will be loaded");
+MODULE_DEVICE_TABLE(usb, zd1201_table);
+
+
+int zd1201_fw_upload(struct usb_device *dev, int apfw)
+{
+ const struct firmware *fw_entry;
+ char* data;
+ unsigned long len;
+ int err;
+ unsigned char ret;
+ char *buf;
+ char *fwfile;
+
+ if (apfw)
+ fwfile = "zd1201-ap.fw";
+ else
+ fwfile = "zd1201.fw";
+
+ err = request_firmware(&fw_entry, fwfile, &dev->dev);
+ if (err) {
+ dev_err(&dev->dev, "Failed to load %s firmware file!\n", fwfile);
+ dev_err(&dev->dev, "Make sure the hotplug firmware loader is installed.\n");
+ dev_err(&dev->dev, "Goto http://linux-lc100020.sourceforge.net for more info\n");
+ return err;
+ }
+
+ data = fw_entry->data;
+len = fw_entry->size;
+
+ buf = kmalloc(1024, GFP_ATOMIC);
+ if (!buf)
+ goto exit;
+
+ wh
Re: [linux-usb-devel] Re: [PATCH] zd1201 wireless lan driver
Damn, I just saw I missed one ESHUTDOWN case...
Please ignore the previous patch.
Jeroen
Description: Driver for ZyDAS zd1201 based usb wireless adapters.
Signed-off-by: Jeroen Vreeken ([EMAIL PROTECTED])
diff -ruN linux-2.6.10.org/CREDITS linux-2.6.10-zd1201/CREDITS
--- linux-2.6.10.org/CREDITS 2004-12-24 22:35:23.0 +0100
+++ linux-2.6.10-zd1201/CREDITS 2005-02-15 21:50:01.0 +0100
@@ -3390,6 +3390,7 @@
E: [EMAIL PROTECTED]
W: http://www.chello.nl/~j.vreeken/
D: SE401 usb webcam driver
+D: ZD1201 usb wireless lan driver
S: Maastrichterweg 63
S: 5554 GG Valkenswaard
S: The Netherlands
diff -ruN linux-2.6.10.org/MAINTAINERS linux-2.6.10-zd1201/MAINTAINERS
--- linux-2.6.10.org/MAINTAINERS 2004-12-24 22:35:00.0 +0100
+++ linux-2.6.10-zd1201/MAINTAINERS 2005-02-15 21:50:01.0 +0100
@@ -2430,6 +2430,14 @@
W: http://www.linux-projects.org
S: Maintained
+USB ZD1201 DRIVER
+P: Jeroen Vreeken
+M: [EMAIL PROTECTED]
+L: linux-usb-users@lists.sourceforge.net
+L: linux-usb-devel@lists.sourceforge.net
+W: http://linux-lc100020.sourceforge.net
+S: Maintained
+
USER-MODE LINUX
P: Jeff Dike
M: [EMAIL PROTECTED]
diff -ruN linux-2.6.10.org/drivers/usb/net/Kconfig linux-2.6.10-zd1201/drivers/usb/net/Kconfig
--- linux-2.6.10.org/drivers/usb/net/Kconfig 2004-12-24 22:35:23.0 +0100
+++ linux-2.6.10-zd1201/drivers/usb/net/Kconfig 2005-02-15 21:49:24.0 +0100
@@ -287,4 +287,21 @@
This driver creates an interface named "ethX", where X depends on
what other networking devices you have in use.
+config USB_ZD1201
+ tristate "USB ZD1201 based Wireless device support"
+ depends on NET_RADIO
+ select FW_LOADER
+ ---help---
+ Say Y if you want to use wireless LAN adapters based on the ZyDAS
+ ZD1201 chip.
+
+ This driver makes the adapter appear as a normal Ethernet interface,
+ typically on wlan0.
+
+ The zd1201 device requires external firmware to be loaded.
+ This can be found at http://linux-lc100020.sourceforge.net/
+
+ To compile this driver as a module, choose M here: the
+ module will be called zd1201.
+
endmenu
diff -ruN linux-2.6.10.org/drivers/usb/net/Makefile linux-2.6.10-zd1201/drivers/usb/net/Makefile
--- linux-2.6.10.org/drivers/usb/net/Makefile 2004-12-24 22:33:49.0 +0100
+++ linux-2.6.10-zd1201/drivers/usb/net/Makefile 2005-02-15 21:49:24.0 +0100
@@ -7,3 +7,6 @@
obj-$(CONFIG_USB_PEGASUS) += pegasus.o
obj-$(CONFIG_USB_RTL8150) += rtl8150.o
obj-$(CONFIG_USB_USBNET) += usbnet.o
+obj-$(CONFIG_USB_ZD1201) += zd1201.o
+
+CFLAGS_zd1201.o = -Idrivers/net/wireless/
diff -ruN linux-2.6.10.org/drivers/usb/net/zd1201.c linux-2.6.10-zd1201/drivers/usb/net/zd1201.c
--- linux-2.6.10.org/drivers/usb/net/zd1201.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.10-zd1201/drivers/usb/net/zd1201.c 2005-02-15 22:24:00.0 +0100
@@ -0,0 +1,1897 @@
+/*
+ * Driver for ZyDAS zd1201 based wireless USB devices.
+ *
+ * Copyright (c) 2004, 2005 Jeroen Vreeken ([EMAIL PROTECTED])
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * Parts of this driver have been derived from a wlan-ng version
+ * modified by ZyDAS. They also made documentation available, thanks!
+ * Copyright (C) 1999 AbsoluteValue Systems, Inc. All Rights Reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "zd1201.h"
+
+static struct usb_device_id zd1201_table[] = {
+ {USB_DEVICE(0x0586, 0x3400)}, /* Peabird Wireless USB Adapter */
+ {USB_DEVICE(0x0ace, 0x1201)}, /* ZyDAS ZD1201 Wireless USB Adapter */
+ {USB_DEVICE(0x050d, 0x6051)}, /* Belkin F5D6051 usb adapter */
+ {USB_DEVICE(0x0db0, 0x6823)}, /* MSI UB11B usb adapter */
+ {}
+};
+
+static int ap = 0; /* Are we an AP or a normal station? */
+
+#define ZD1201_VERSION "0.15"
+
+MODULE_AUTHOR("Jeroen Vreeken <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Driver for ZyDAS ZD1201 based USB Wireless adapters");
+MODULE_VERSION(ZD1201_VERSION);
+MODULE_LICENSE("GPL");
+module_param(ap, int, 0);
+MODULE_PARM_DESC(ap, "If non-zero Access Point firmware will be loaded");
+MODULE_DEVICE_TABLE(usb, zd1201_table);
+
+
+int zd1201_fw_upload(struct usb_device *dev, int apfw)
+{
+ const struct firmware *fw_entry;
+ char* data;
+ unsigned long len;
+ int err;
+ unsigned char ret;
+ char *buf;
+ char *fwfile;
+
+ if (apfw)
+ fwfile = "zd1201-ap.fw";
+ else
+ fwfile = "zd1201.fw";
+
+ err = request_firmware(&fw_entry, fwfile, &dev->dev);
+ if (err) {
+ dev_err(&dev->dev, "Failed to load %s firmware file!\n", fwfile);
+ dev_err(&dev->dev, "Make sure the hotplug firmware loader is installed.\n");
+ dev_err(&dev->dev, "Goto http://linux-lc100020.sourceforge.net for more info\n");
+ return err;
+ }
+
+ data = fw_entry->data;
+len = fw_entry->size;
+
+ buf = kmalloc(1024, GFP_ATOMIC);
+
Re: [linux-usb-devel] Re: [PATCH] zd1201 wireless lan driver
Am Dienstag, 15. Februar 2005 22:10 schrieb Jeroen Vreeken:
> Thanks for the tips Oliver.
> Here is the third attempt.
+/* Incomming data */
+void zd1201_usbrx(struct urb *urb, struct pt_regs *regs)
[..]
+ switch(urb->status) {
+ case -EILSEQ:
+ case -ENODEV:
+ case -ETIMEDOUT:
+ case -ENOENT:
+ case -EPIPE:
ESHUTDOWN
+ if (type == ZD1201_PACKET_EVENTSTAT || type == ZD1201_PACKET_RESOURCE) {
+ memcpy(zd->rxdata, data, urb->actual_length);
+ zd->rxlen = urb->actual_length;
+ zd->rxdatas = 1;
+ wake_up(&zd->rxdataq);
+ }
What will happen to the waiting task if the error path is taken
or resubmission fails?
+ if (wait) {
+ wait_event_interruptible(zd->rxdataq, zd->rxdatas);
+ if (!zd->rxlen || zd2host16(*(short*)&zd->rxdata[6]) != rid) {
+ dev_dbg(&zd->usb->dev, "wrong or no RID received\n");
+ }
+ }
You could avoid some GFP_ATOMIC allocations here checking the flag.
+int zd1201_drvr_start(struct zd1201 *zd)
+{
+ int err, i;
+ short max;
+ unsigned char *buffer;
+
+ buffer = kmalloc(ZD1201_RXSIZE, GFP_ATOMIC);
This is called from probe() only. Use GFP_KERNEL.
+err_urb:
+ zd->tx_urb->transfer_flags |= URB_ASYNC_UNLINK;
+ usb_unlink_urb(zd->rx_urb);
+ return err;
You must make sure that the descriptor referenced in the irq handler is not
freed before this operation completes. Best use usb_kill_urb(). You don't need
to be atomic.
+static void zd1201_tx_timeout(struct net_device *dev)
+{
+ struct zd1201 *zd = (struct zd1201 *)dev->priv;
+
+ if (!zd)
+ return;
+ dev_warn(&zd->usb->dev, "%s: TX timeout, shooting down urb\n",
+ dev->name);
+ zd->tx_urb->transfer_flags |= URB_ASYNC_UNLINK;
+ usb_unlink_urb(zd->tx_urb);
+ zd->stats.tx_errors++;
+ /* Restart the timeout to quiet the watchdog: */
+ dev->trans_start = jiffies;
+ usb_free_urb(zd->tx_urb);
+ /* Restart the net queue: */
+ zd->tx_urb = usb_alloc_urb(0, GFP_ATOMIC);
+ if (zd->tx_urb)
+ netif_wake_queue(dev);
+}
This is very ingenious, but it has another race. The interrupt handler
will activate the queue at some random time in the future.
May I suggest that you use a work queue and a synchronous usb_kill_urb()
in that?
+ zd->endp_in = 1;
+ zd->endp_out = 1;
+ zd->endp_out2 = 2;
+ zd->rx_urb = usb_alloc_urb(0, GFP_ATOMIC);
+ zd->tx_urb = usb_alloc_urb(0, GFP_ATOMIC);
+ if (!zd->rx_urb || !zd->tx_urb)
+ goto err_zd;
Use GFP_KERNEL
+void zd1201_disconnect(struct usb_interface *interface)
You should use usb_kill_urb() on all URBs in question.
Regards
Oliver
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch 2.6] usbnet uses NET_IP_ALIGN
On Fri, Feb 11, 2005 at 11:55:12AM -0800, David Brownell wrote: > Hmm, another ARM platform craves aligned buffers. In this case, it turned > up the fact that the alignment handler on a big-endian ARM misbehaves. > Please merge. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch 2.6.11-rc] ehci updates for TDI/ATG silicon
On Mon, Feb 07, 2005 at 12:30:21PM -0800, David Brownell wrote: > This mostly changes the company name from ATG to TDI (TransDimension), > but it also updates initialization and split ISO support for that part's > integrated transaction translator. Please merge. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch 2.6.11-rc] ethernet gadget driver aligns IP headers
On Mon, Feb 07, 2005 at 12:23:29PM -0800, David Brownell wrote: > This is important on one board, but is otherwise just a performance tweak. > Please merge. > Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch 2.6.11-rc] teach gadget drivers about s3c2410_udc
On Thu, Feb 10, 2005 at 12:23:06PM -0800, David Brownell wrote: > As used in various boards including the iPaq h1940; please merge. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Linux 2.6.x stops polling for data on bulk pipe
On Monday 14 February 2005 9:17 am, Steve Hosgood wrote: > > qh/cf49c100 dev2 hs ep2 42002202 4000 (8a00ad80* data1 nak0) > da98f360 in len=0 4d00 urb d6189b00 > da98f480*in len=12288 b0008d80 urb d6189b00 > da98f420+in len=20480 5d80 urb d4452680 > da98f540 in len=12288 b0008d80 urb d4452680 > da98f4e0#in len=20480 5d80 urb d6189900 > da98f600 in len=12288 b0008d80 urb d6189900 > ... > > Now for the non-working situation of 800x600 images @ 40fps: And this is "non-working" in that you verified, using a CATC or equivalent, that the host wasn't sending any IN tokens to the device at all? > qh/cf49c100 dev2 hs ep2 42002202 4000 (0400ad80* data0 nak3) > da98f360 in len=0 4d00 urb d6189b00 > da98f480*in len=12288 b0008d80 urb d6189b00 > da98f420+in len=20480 5d80 urb c2609a80 > da98f540 in len=12288 b0008d80 urb c2609a80 > da98f4e0#in len=20480 5d80 urb d6189a00 > da98f600 in len=12288 b0008d80 urb d6189a00 The thing that's obviously striking here is that your urbs have 32KB buffers, so each one stretches into two qTDs: the first is five pages, the second is three. (And nothing looks obviously wrong in those parts of the queue heads.) Now while that's normally a fine thing, it's also a mode that doesn't usually kick in ... AND it's one where some shenanigans have to be used to patch up short reads. AND you're seeing problems after some short reads. Specifically, when the first TD (len=20480) triggers any kind of short read, it enters a special patch-up mode (flagged by the '#') where instead of going to the next TD, it goes to a magic "alternate" dummy that just stops the whole queue ... and the queue scanning logic has to detect that magic dummy, and restart it. ==> HYPOTHESIS: there's a bug in how the queue scanning handles that special case. It's very rare; QED. ==> PLEASE TEST BY: trying buffers of no more than 5KB in your bulk-IN urbs. This will completely avoid those special cases. If it checks out, there can be a couple ways to fix it. The "slow" way would just identify how that special casing is goofed, and resolve the issue. The "fast" way would be to use that "alternate" in a smarter way, so the hardware immediately jumps to the next URB. (And change how the single-URB unlink logic works, too.) Also ==> HYPOTHESIS: this is more hardware that behaves oddly with the "park" mode. A recent patch disabled that, improving behavior on some NForce2 boards. ==> TEST BY: using 2.6.11-rc4, which turns off that park mode. In general, reporting test results with a vendor kernel is not going to be as useful as reporting ones with the most current www.kernel.org code ... unless you're dealing with the vendor. - Dave --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] state of usb-gadget.bkbits.net:8080/gadget-2.4 tree
On Tuesday 15 February 2005 7:00 am, Kumar Gala wrote: > David, So far as I know, David Howells has nothing to do with that tree. He may be as puzzled as me about why you're asking him the question! > I was wondering what the state of the > usb-gadget.bkbits.net:8080/gadget-2.4 tree was. It appears that some > changes got accepted into this tree (ARC EHCI TT host support). State of that tree is much the same as other 2.4 kernel trees: it's not getting updates. Except maybe for critical patches, and the occasional pull of 2.4.current (which anyone can do into their own clone). The primary purpose of that tree is to hold 2.4 versions of the gadget framework code; anything else is gravy. In particular, note www.linux-usb.org/usb2.html highlights the fact that "2.4 versions of the EHCI driver are no longer being kept current". That's both with respect to the www.kernel.org version, and the slightly different version in that gadget-2.4 tree. > Is there a patch of this against some stock 2.4 tree around somewhere? No, but they're easy to generate. In fact, see the BK-HOWTO in the kernel documentation directory ... there's a very useful command at the end. - Dave --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] zd1201 wireless lan driver
Oliver Neukum wrote:
+static void zd1201_tx_timeout(struct net_device *dev)
+{
+ struct zd1201 *zd = (struct zd1201 *)dev->priv;
+
+ if (!zd)
+ return;
+ dev_warn(&zd->usb->dev, "%s: TX timeout, shooting down urb\n",
+ dev->name);
+ zd->tx_urb->transfer_flags |= URB_ASYNC_UNLINK;
+ usb_unlink_urb(zd->tx_urb);
+ zd->stats.tx_errors++;
+ /* Restart the timeout to quiet the watchdog: */
+ dev->trans_start = jiffies;
+ usb_free_urb(zd->tx_urb);
+ /* Restart the net queue: */
+ zd->tx_urb = usb_alloc_urb(0, GFP_ATOMIC);
+ if (zd->tx_urb)
+ netif_wake_queue(dev);
+}
This is very ingenious, but it has another race. The interrupt handler
will activate the queue at some random time in the future.
May I suggest that you use a work queue and a synchronous usb_kill_urb()
in that?
It just came to me that I don't need any off the above magic at all
I can just unlink it and the completion handler will wake the queue
anyway...
So here is yet another try...
Jeroen
Description: Driver for ZyDAS zd1201 based usb wireless adapters.
Signed-off-by: Jeroen Vreeken ([EMAIL PROTECTED])
diff -ruN linux-2.6.10.org/CREDITS linux-2.6.10-zd1201/CREDITS
--- linux-2.6.10.org/CREDITS 2004-12-24 22:35:23.0 +0100
+++ linux-2.6.10-zd1201/CREDITS 2005-02-16 00:19:41.0 +0100
@@ -3390,6 +3390,7 @@
E: [EMAIL PROTECTED]
W: http://www.chello.nl/~j.vreeken/
D: SE401 usb webcam driver
+D: ZD1201 usb wireless lan driver
S: Maastrichterweg 63
S: 5554 GG Valkenswaard
S: The Netherlands
diff -ruN linux-2.6.10.org/MAINTAINERS linux-2.6.10-zd1201/MAINTAINERS
--- linux-2.6.10.org/MAINTAINERS 2004-12-24 22:35:00.0 +0100
+++ linux-2.6.10-zd1201/MAINTAINERS 2005-02-16 00:19:41.0 +0100
@@ -2430,6 +2430,14 @@
W: http://www.linux-projects.org
S: Maintained
+USB ZD1201 DRIVER
+P: Jeroen Vreeken
+M: [EMAIL PROTECTED]
+L: linux-usb-users@lists.sourceforge.net
+L: linux-usb-devel@lists.sourceforge.net
+W: http://linux-lc100020.sourceforge.net
+S: Maintained
+
USER-MODE LINUX
P: Jeff Dike
M: [EMAIL PROTECTED]
diff -ruN linux-2.6.10.org/drivers/usb/net/Kconfig linux-2.6.10-zd1201/drivers/usb/net/Kconfig
--- linux-2.6.10.org/drivers/usb/net/Kconfig 2004-12-24 22:35:23.0 +0100
+++ linux-2.6.10-zd1201/drivers/usb/net/Kconfig 2005-02-16 00:18:58.0 +0100
@@ -287,4 +287,21 @@
This driver creates an interface named "ethX", where X depends on
what other networking devices you have in use.
+config USB_ZD1201
+ tristate "USB ZD1201 based Wireless device support"
+ depends on NET_RADIO
+ select FW_LOADER
+ ---help---
+ Say Y if you want to use wireless LAN adapters based on the ZyDAS
+ ZD1201 chip.
+
+ This driver makes the adapter appear as a normal Ethernet interface,
+ typically on wlan0.
+
+ The zd1201 device requires external firmware to be loaded.
+ This can be found at http://linux-lc100020.sourceforge.net/
+
+ To compile this driver as a module, choose M here: the
+ module will be called zd1201.
+
endmenu
diff -ruN linux-2.6.10.org/drivers/usb/net/Makefile linux-2.6.10-zd1201/drivers/usb/net/Makefile
--- linux-2.6.10.org/drivers/usb/net/Makefile 2004-12-24 22:33:49.0 +0100
+++ linux-2.6.10-zd1201/drivers/usb/net/Makefile 2005-02-16 00:18:58.0 +0100
@@ -7,3 +7,6 @@
obj-$(CONFIG_USB_PEGASUS) += pegasus.o
obj-$(CONFIG_USB_RTL8150) += rtl8150.o
obj-$(CONFIG_USB_USBNET) += usbnet.o
+obj-$(CONFIG_USB_ZD1201) += zd1201.o
+
+CFLAGS_zd1201.o = -Idrivers/net/wireless/
diff -ruN linux-2.6.10.org/drivers/usb/net/zd1201.c linux-2.6.10-zd1201/drivers/usb/net/zd1201.c
--- linux-2.6.10.org/drivers/usb/net/zd1201.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.10-zd1201/drivers/usb/net/zd1201.c 2005-02-16 00:19:00.0 +0100
@@ -0,0 +1,1903 @@
+/*
+ * Driver for ZyDAS zd1201 based wireless USB devices.
+ *
+ * Copyright (c) 2004, 2005 Jeroen Vreeken ([EMAIL PROTECTED])
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * Parts of this driver have been derived from a wlan-ng version
+ * modified by ZyDAS. They also made documentation available, thanks!
+ * Copyright (C) 1999 AbsoluteValue Systems, Inc. All Rights Reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "zd1201.h"
+
+static struct usb_device_id zd1201_table[] = {
+ {USB_DEVICE(0x0586, 0x3400)}, /* Peabird Wireless USB Adapter */
+ {USB_DEVICE(0x0ace, 0x1201)}, /* ZyDAS ZD1201 Wireless USB Adapter */
+ {USB_DEVICE(0x050d, 0x6051)}, /* Belkin F5D6051 usb adapter */
+ {USB_DEVICE(0x0db0, 0x6823)}, /* MSI UB11B usb adapter */
+ {}
+};
+
+static int ap = 0; /* Are we an AP or a normal station? */
+
+#define ZD1201_VERSION "0.15"
+
+MODULE_AUTHOR("Jeroen Vreeken
Re: [linux-usb-devel] state of usb-gadget.bkbits.net:8080/gadget-2.4 tree
On Feb 15, 2005, at 5:16 PM, David Brownell wrote: On Tuesday 15 February 2005 7:00 am, Kumar Gala wrote: > David, So far as I know, David Howells has nothing to do with that tree. He may be as puzzled as me about why you're asking him the question! Sorry, this is what I get for sending email first thing in the morning. > I was wondering what the state of the > usb-gadget.bkbits.net:8080/gadget-2.4 tree was. It appears that some > changes got accepted into this tree (ARC EHCI TT host support). State of that tree is much the same as other 2.4 kernel trees: it's not getting updates. Except maybe for critical patches, and the occasional pull of 2.4.current (which anyone can do into their own clone). The primary purpose of that tree is to hold 2.4 versions of the gadget framework code; anything else is gravy. In particular, note www.linux-usb.org/usb2.html highlights the fact that "2.4 versions of the EHCI driver are no longer being kept current". That's both with respect to the www.kernel.org version, and the slightly different version in that gadget-2.4 tree. > Is there a patch of this against some stock 2.4 tree around somewhere? No, but they're easy to generate. In fact, see the BK-HOWTO in the kernel documentation directory ... there's a very useful command at the end. Ok, well do, just wasnt sure what was on the shelf already. = kumar --- 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_ide95&alloc_id396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Patch to change error code for "device not responding"
On Friday 11 February 2005 7:39 am, Alan Stern wrote: > > How about this patch instead? > > Alan Stern I like it much better. As doc, it might even still make 2.6.11 ... ;) > > = Documentation/usb/error-codes.txt 1.15 vs edited = > --- 1.15/Documentation/usb/error-codes.txt2005-01-18 15:22:31 -05:00 > +++ edited/Documentation/usb/error-codes.txt 2005-02-11 10:32:26 -05:00 > @@ -88,13 +91,19 @@ > prescribed bus turn-around time > c) unknown USB error > > - In cases b) and c) either -EPROTO or -EILSEQ > - may be returned. Note that often the controller > - hardware does not distinguish among cases a), > - b), and c), so a driver cannot tell whether > - there was a protocol error, a failure to respond > - (often caused by device disconnect), or some > - other fault. > + Note that often the controller hardware does not > + distinguish among cases a), b), and c), so a > + driver cannot tell whether there was a protocol > + error, a failure to respond (often caused by > + device disconnect), or some other fault. > + > +-ETIMEDOUT (**) No response packet received within the > prescribed > + bus turn-around time. This error may instead be > + reported as -EPROTO or -EILSEQ. > + > + Note that the synchronous USB message functions > + also use this code to indicate timeout expired > + before the transfer completed. > > -EPIPE (**) Endpoint stalled. For non-control endpoints, > reset this status with usb_clear_halt(). > @@ -152,4 +161,7 @@ > usb_get_*/usb_set_*(): > usb_control_msg(): > usb_bulk_msg(): > --ETIMEDOUT timeout expired before the transfer completed > +-ETIMEDOUT Timeout expired before the transfer completed. > + In the future this code may change to -ETIME, > + whose definition is a closer match to this sort > + of error. > > --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Question about evdev
Hi Vojtech, I have a question about the "contract" of the evdev interface... I have 2 touch screens, both USB. Both of them have drivers (hid-input and mtouchusb) that provide ABS_X and ABS_Y coordinates to the input subsystem and so I read those coordinates from userspace. However, one of the touch screens (ELO, via hid-input) reports coordinates with the origin in the upper-left corner, i.e. touching the upper-left corner of the screen reports 0,0. The other touch screen (3M, via mtouchusb) reports coordinates with the origin at the bottom-left corner. So my question is, can an evdev app assume a specific origin? Normal screen origin, i.e. upper-left, would make the most sense to me. If so, it seems that mtouchusb should flip its Y coordinates before sending to the input subsystem (which would be an easy patch of course). Or, can an app not rely on evdev's coordinate origin being upper-left? Thanks! -- Dan Streetman [EMAIL PROTECTED] - 186,272 miles per second: It isn't just a good idea, it's the law! --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] mtouchusb coordinate data raw vs. calibrated
Hi Todd, In mtouchusb, you switched back to raw coordinate data, from calibrated coordinate data...but, isn't it better to report calibrated coordinate data? Could we patch the driver to go back to calibrated coordinate data? -- Dan Streetman [EMAIL PROTECTED] - 186,272 miles per second: It isn't just a good idea, it's the law! --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] calibrate a touchscreen via evdev?
Hi Vojtech, I'm trying to figure out what the best way to calibrate a touch screen is. I have a 3M touchscreen driven via mtouchusb, and I access it through evdev. So, I'd like to be able to initiate hardware calibration via evdev also. But I'm not sure what the best command to send through evdev would be? All I really see to talk back to the device is FF, but that doesn't seem to fit a calibration command...? FYI, the hardware calibration sequence/command for (simple 2-point) hardware calibration of the 3M (EXII 5000UC) USB touchscreen is defined in the spec: http://www.3m.com/3MTouchSystems/downloads/tecdoc.jhtml and it's just a single USB Vendor Request. After the request the touchscreen uses the next 2 touches to do internal hardware calibration. Thanks! -- Dan Streetman [EMAIL PROTECTED] - 186,272 miles per second: It isn't just a good idea, it's the law! --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH as465] Clear endpoint toggles in usb_set_interface
On Wed, Feb 09, 2005 at 01:10:59PM -0500, Alan Stern wrote: > Greg: > > Pete Zaitcev has found some USB devices that don't reset their endpoint > data toggles when they get a SET-INTERFACE request. Apparently they > interpret the USB specification too literally when it says that the > toggles must be reset whenever the alternate setting is "changed". > > Anyway, this patch calls usb_clear_halt for all endpoints in the > altsetting whenever usb_set_interface is called and the new altsetting is > the same as the old one. It adds some extra overhead for the majority of > devices that don't need it, but fortunately usb_set_interface isn't called > very often. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCHES as424c-426c, as456-462 (0/10)] USBcore: implement usb_add_hcd and usb_remove_hcd
On Tue, Feb 08, 2005 at 03:46:21PM -0500, Alan Stern wrote: > Greg and others: > > This series of patches centralizes much of the functionality required for > creating, registering, and removing hcd and bus structures into the core. > It removes a lot of duplication among various HC drivers. It also removes > a class of bugs in which drivers would call their stop() routines when > start() returned an error. > > A few small internal changes were made along the way. The string used to > register a driver's IRQ line now includes the bus number along with the > driver name. The rather ad-hoc use of fields in the hcd structure to > store resource locations and pointers is now rationalized and consistent. > All drivers now use the central usb_hcd_irq handler. Resources are now > correctly reported as either iomem or iobase. > > The changes to the core and each of the different drivers will come in the > following messages, with copies sent to the respective authors and > maintainers. I haven't been able to test the non-PCI drivers, but at > least the ARM-based ones and the SL811 driver can be compiled. > > Unless there are comments or objections, these patches are ready to be > applied. Thanks, I've applied all of them except as460 as there seemed to be confusion about that one. Care to respin that one based on all of the comments given to it? thanks, greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] 2.6.11-rc3 remove debug message
On Sat, Feb 12, 2005 at 12:57:39PM +0100, Brian Murphy wrote: > Hi, > this removes a warning message which only contains > data which is in any case returned to user space. This message > is especially annoying when polling with short timeouts, filling > up the log files and polluting the console. As agreed with > David Brownell. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 2.6] maintainers / documentation update cyberjack
On Tue, Feb 15, 2005 at 12:54:41AM +0100, Harald Welte wrote: > Here's a pure documentation update for the cyberjack driver. > > Please apply at your convenience, thanks. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] 2.6.11-rc3 set timeout message to debug level: message.c
On Sat, Feb 12, 2005 at 12:55:58PM +0100, Brian Murphy wrote: > Hi, > this makes a the debug message on timeout be at debug level > so it only exists when compiling with explicit debugging support. > I have added information about the request length and data length > as now if the data length is non-zero a 0 status is returned. > > This depends on the previous data-loss patch. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH as464] Fix race: URB submission vs. endpoint-disable
On Wed, Feb 09, 2005 at 01:04:46PM -0500, Alan Stern wrote: > Greg: > > This patch fixes a race between URB submission and endpoint-disable. (I > don't know that it's actually possible to trigger the race, but it won't > hurt to move the appropriate test inside the region protected by the > spinlock.) In addition, an out-of-date comment referring to timeouts is > removed. > > The patch also changes the error code returned when an URB is submitted > for a nonexistent or disabled endpoint to -ENOENT and documents the error > code (which was already in use by usbfs) in > Documentation/usb/error-codes.txt. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH as467] usb-storage: Don't log expected signatures
On Thu, Feb 10, 2005 at 04:41:30PM -0500, Alan Stern wrote: > Greg: > > This fairly trivial patch makes three small changes: > > Correct a typo in a comment. > > Don't print a debugging message when a USB mass-storage device > uses the standard signature (the one we would expect normally). > > Shorten a debugging message and add a newline. > > Please apply. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: pegasus and rtl8150 cset for proper link detection
On Thu, Feb 03, 2005 at 06:20:38PM +0200, Petko Manolov wrote: > Hi Greg, > > When the bonding driver attempts to read the link status via > xxx_get_settings() the enslaved usb-eth driver crash the kernel. Which > shouldn't be much of surprise - since pegasus|rtl8150_get_settins() is > been called from a timer. The original work was done by Mike Nix - > thanks. > > Fixed that using in_atomic() check. I am not sure this is the best/proper > thing to do, although it seems to work. > > Haven't checked the other usb-ethernet drivers, but i suspect they are as > vulnerable as pegasus and rtl8150 are. It's probably a good idea to warn > their respective maintainers. Hm, I get the following build error with this patch: drivers/usb/net/pegasus.c: In function `check_carrier': drivers/usb/net/pegasus.c:1167: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c: In function `pegasus_probe': drivers/usb/net/pegasus.c:1198: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c:1198: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c:1198: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c:1198: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c:1198: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c:1198: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c:1198: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c:1198: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c:1244: error: structure has no member named `carrier_check' drivers/usb/net/pegasus.c: In function `pegasus_disconnect': drivers/usb/net/pegasus.c:1271: error: structure has no member named `carrier_check' So I'm not going to apply it :) thanks, greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] 2.6.11-rc3 fix for data loss in message.c
On Sat, Feb 12, 2005 at 12:52:39PM +0100, Brian Murphy wrote: > Hi, > This is my fix for usbfs losing data when the urb > is timed out but already contains data. Applied, thanks. greg k-h --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Error with usb storage
I am trying to get a usb digital camera that is supposed to work through usb storage. It works fine under win XP with the standard usb-storage driver. I compiled the kernel with debug messages and got the following output in response to connecting the camera. The errors I can see are a few usb-storage: Bulk logical error usb-storage: -- transport indicates error, resetting then usb-storage: Bulk logical error usb-storage: -- transport indicates error, resetting and then several usb-storage: Bad target number ([1234567]:0) Any ideas if it is possible to get this thing working ? Thanks usb 1-2: new full speed USB device using uhci_hcd and address 2 SCSI subsystem initialized Initializing USB Mass Storage driver... usb-storage: USB Mass Storage device detected usb-storage: -- associate_dev usb-storage: Vendor: 0x0762, Product: 0x7941, Revision: 0x usb-storage: Interface Subclass: 0x06, Protocol: 0x50 usb-storage: Vendor: Unknown, Product: Unknown usb-storage: Transport: Bulk usb-storage: Protocol: Transparent SCSI usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value= index=00 len=1 usb-storage: GetMaxLUN command result is 1, data is 1 scsi0 : SCSI emulation for USB Mass Storage devices usbcore: registered new driver usb-storage USB Mass Storage support registered. usb-storage: *** thread sleeping. usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command INQUIRY (6 bytes) usb-storage: 12 00 00 00 24 00 usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes usb-storage: Status code 0; transferred 36/36 usb-storage: -- transfer complete usb-storage: Bulk data transfer result 0x0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425300 T 0x1 R 0 Stat 0x0 usb-storage: Bulk logical error usb-storage: -- transport indicates error, resetting usb-storage: usb_stor_Bulk_reset called usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 usb-storage: command_abort called usb-storage: Soft reset: clearing bulk-in endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=81 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset: clearing bulk-out endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=01 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset done usb-storage: scsi cmd done, result=0x7 usb-storage: *** thread sleeping. usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command TEST_UNIT_READY (6 bytes) usb-storage: 00 00 00 00 00 00 usb-storage: Bulk Command S 0x43425355 T 0x1 L 0 F 0 Trg 0 LUN 0 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425300 T 0x1 R 0 Stat 0x0 usb-storage: Bulk logical error usb-storage: -- transport indicates error, resetting usb-storage: usb_stor_Bulk_reset called usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 usb-storage: Soft reset: clearing bulk-in endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=81 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset: clearing bulk-out endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=01 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset done usb-storage: scsi cmd done, result=0x7 usb-storage: *** thread sleeping. usb-storage: device_reset called usb-storage: usb_stor_Bulk_reset called usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 usb-storage: Soft reset: clearing bulk-in endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=81 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset: clearing bulk-out endpoint halt usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=01 len=0 usb-storage: usb_stor_clear_halt: result = 0 usb-storage: Soft reset done usb-storage: queuecommand called usb-storage: *** thread awakened. usb-storage: Command TEST_UNIT_READY (6 bytes) usb-storage: 00 00 00 00 00 00 usb-storage: Bulk Command S 0x4
Re: [linux-usb-devel] Error with usb storage
Your device violates the specification by not using the correct CSW Signature. Patches to adjust for this are already being merged. Matt On Wed, Feb 16, 2005 at 03:14:19AM +0200, Micha Feigin wrote: > I am trying to get a usb digital camera that is supposed to work through usb > storage. It works fine under win XP with the standard usb-storage driver. > > I compiled the kernel with debug messages and got the following output in > response to connecting the camera. The errors I can see are a few > > usb-storage: Bulk logical error > usb-storage: -- transport indicates error, resetting > > then > > usb-storage: Bulk logical error > usb-storage: -- transport indicates error, resetting > > and then several > > usb-storage: Bad target number ([1234567]:0) > > Any ideas if it is possible to get this thing working ? > > Thanks > > usb 1-2: new full speed USB device using uhci_hcd and address 2 > SCSI subsystem initialized > Initializing USB Mass Storage driver... > usb-storage: USB Mass Storage device detected > usb-storage: -- associate_dev > usb-storage: Vendor: 0x0762, Product: 0x7941, Revision: 0x > usb-storage: Interface Subclass: 0x06, Protocol: 0x50 > usb-storage: Vendor: Unknown, Product: Unknown > usb-storage: Transport: Bulk > usb-storage: Protocol: Transparent SCSI > usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value= index=00 len=1 > usb-storage: GetMaxLUN command result is 1, data is 1 > scsi0 : SCSI emulation for USB Mass Storage devices > usbcore: registered new driver usb-storage > USB Mass Storage support registered. > usb-storage: *** thread sleeping. > usb-storage: device found at 2 > usb-storage: waiting for device to settle before scanning > usb-storage: queuecommand called > usb-storage: *** thread awakened. > usb-storage: Command INQUIRY (6 bytes) > usb-storage: 12 00 00 00 24 00 > usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes > usb-storage: Status code 0; transferred 36/36 > usb-storage: -- transfer complete > usb-storage: Bulk data transfer result 0x0 > usb-storage: Attempting to get CSW... > usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > usb-storage: Status code 0; transferred 13/13 > usb-storage: -- transfer complete > usb-storage: Bulk status result = 0 > usb-storage: Bulk Status S 0x53425300 T 0x1 R 0 Stat 0x0 > usb-storage: Bulk logical error > usb-storage: -- transport indicates error, resetting > usb-storage: usb_stor_Bulk_reset called > usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 > usb-storage: command_abort called > usb-storage: Soft reset: clearing bulk-in endpoint halt > usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=81 len=0 > usb-storage: usb_stor_clear_halt: result = 0 > usb-storage: Soft reset: clearing bulk-out endpoint halt > usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=01 len=0 > usb-storage: usb_stor_clear_halt: result = 0 > usb-storage: Soft reset done > usb-storage: scsi cmd done, result=0x7 > usb-storage: *** thread sleeping. > usb-storage: queuecommand called > usb-storage: *** thread awakened. > usb-storage: Command TEST_UNIT_READY (6 bytes) > usb-storage: 00 00 00 00 00 00 > usb-storage: Bulk Command S 0x43425355 T 0x1 L 0 F 0 Trg 0 LUN 0 CL 6 > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > usb-storage: Status code 0; transferred 31/31 > usb-storage: -- transfer complete > usb-storage: Bulk command transfer result=0 > usb-storage: Attempting to get CSW... > usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > usb-storage: Status code 0; transferred 13/13 > usb-storage: -- transfer complete > usb-storage: Bulk status result = 0 > usb-storage: Bulk Status S 0x53425300 T 0x1 R 0 Stat 0x0 > usb-storage: Bulk logical error > usb-storage: -- transport indicates error, resetting > usb-storage: usb_stor_Bulk_reset called > usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 > usb-storage: Soft reset: clearing bulk-in endpoint halt > usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=81 len=0 > usb-storage: usb_stor_clear_halt: result = 0 > usb-storage: Soft reset: clearing bulk-out endpoint halt > usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=01 len=0 > usb-storage: usb_stor_clear_halt: result = 0 > usb-storage: Soft reset done > usb-storage: scsi cmd done, result=0x7 > usb-storage: *** thread sleeping. > usb-storage: device_reset called > usb-storage: usb_stor_Bulk_reset called > usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 > usb-storage: Soft reset: clearing bulk-in endpoint halt > usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=81 len=0 > usb-storage: u
[linux-usb-devel] Unable to read after closing usb-serial device
Hi, i'm having a problem with an application of mine that communicates with (Ba usb-serial device. (B (BIt seems that after running a sample application (to send a command 10 (Btimes), (Bif you run the same application again, the application cannot read from (Busb-serial. I have (Bto execute command "stty -F /dev/ttyUSB0" to be able to run the same (Bapplication and (Bread the responses. Maybe something is wrong with how I close the usb-serial (Bport. (B (BProcedure: (B1.) Run application (sending command and reading response 10 times) (B2.) What is displayed 10 times (BCommand sent: size 2 (BRead: 3 (BResponse: 90 00 AA (B3.) Application ends (B4.) Run application again (B5.) What is displayed (BCommand sent: size 2 (BRead: 0 (B (B/proc/device, /var/log/syslog, /proc/bus/usb/devices are right below. (BI've also included the outputs of dmesg, lsmod and lsusb. (B (BI hope you can help me. And thanks. (B (BSincerely, (BMeema (B (BMa. Kharisma V. Esguerra (BSystem Engineer I (BEpson Precision (Philippines), Inc. - Cebu Office (BModule 7A, e-Office, Asiatown I.T. Park, (BApas, Cebu City, 6000 Philippines (BTel. Nos. (+63 32) 412-7511 to 13 (BFax No. (+63 32) 412-7514 (B (B /PROC/DEVICES --- (BCharacter devices: (B 1 mem (B 2 pty/m%d (B 3 pty/s%d (B 4 tts/%d (B 5 cua/%d (B 7 vcs (B 10 misc (B 21 sg (B109 lvm (B128 ptm (B136 pts/%d (B162 raw (B180 usb (B188 usb/tts/%d (B202 cpu/msr (B203 cpu/cpuid (B (BBlock devices: (B 1 ramdisk (B 2 fd (B 7 loop (B 8 sd (B 9 md (B 58 lvm (B 65 sd (B 66 sd (B114 ataraid (B /PROC/DEVICES --- (B (B /VAR/LOG/SYSLOG --- (BFeb 10 17:57:01 posx syslogd 1.4.1: restart. (BFeb 10 17:57:01 posx kernel: md: md driver 0.90.0 MAX_MD_DEVS=256, (BMD_SB_DISKS=27 (BFeb 10 17:57:01 posx kernel: md: raid1 personality registered as nr 3 (BFeb 10 17:57:01 posx kernel: md: raid0 personality registered as nr 2 (BFeb 10 17:57:01 posx kernel: raid5: measuring checksumming speed (BFeb 10 17:57:01 posx kernel:8regs : 2399.600 MB/sec (BFeb 10 17:57:01 posx kernel:32regs: 1538.000 MB/sec (BFeb 10 17:57:01 posx kernel:pIII_sse : 3354.000 MB/sec (BFeb 10 17:57:01 posx kernel:pII_mmx : 3583.600 MB/sec (BFeb 10 17:57:01 posx kernel:p5_mmx: 3598.800 MB/sec (BFeb 10 17:57:01 posx kernel: raid5: using function: pIII_sse (3354.000 (BMB/sec) (BFeb 10 17:57:01 posx kernel: md: raid5 personality registered as nr 4 (BFeb 10 17:57:01 posx kernel: md: multipath personality registered as nr 7 (BFeb 10 17:57:01 posx kernel: md: linear personality registered as nr 1 (BFeb 10 17:57:01 posx kernel: LVM version 1.0.7(28/03/2003) module loaded (BFeb 10 17:57:01 posx kernel: usb.c: registered new driver serial (BFeb 10 17:57:01 posx kernel: usbserial.c: USB Serial support registered for (BGeneric (BFeb 10 17:57:01 posx kernel: usbserial.c: Generic converter detected (BFeb 10 17:57:01 posx kernel: usbserial.c: Generic converter now attached to (BttyUSB0 (or usb/tts/0 for devfs) (BFeb 10 17:57:01 posx kernel: usbserial.c: Generic converter detected (BFeb 10 17:57:01 posx kernel: usbserial.c: Generic device with no bulk out, (Bnot allowed. (BFeb 10 17:57:01 posx kernel: usbserial.c: USB Serial Driver core v1.4 (BFeb 10 17:57:01 posx ntpd[209]: ntpd [EMAIL PROTECTED] Wed Dec 24 00:40:39 PST (B2003 (1) (BFeb 10 17:57:01 posx ntpd[209]: signal_no_reset: signal 13 had flags 400 (BFeb 10 17:57:01 posx ntpd[209]: precision = 6 usec (BFeb 10 17:57:01 posx ntpd[209]: kernel time discipline status 0040 (BFeb 10 17:57:01 posx ntpd[209]: getconfig: Couldn't open (BFeb 10 17:57:02 posx /usr/sbin/cron[1700]: (CRON) INFO (pidfile fd = 5) (BFeb 10 17:57:02 posx /usr/sbin/cron[1701]: (CRON) STARTUP (fork ok) (BFeb 10 17:57:02 posx /usr/sbin/cron[1701]: (CRON) INFO (Running @reboot (Bjobs) (B /VAR/LOG/SYSLOG --- (B (B /PROC/BUS/USB/DEVICES --- (BT: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 (BB: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 (BD: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS= 8 #Cfgs= 1 (BP: Vendor= ProdID= Rev= 2.04 (BS: Manufacturer=Linux 2.4.20-8 ehci-hcd (BS: Product=PCI device 8086:24cd (BS: SerialNumber=00:1d.7 (BC:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA (BI: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub (BE: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms (BT: Bus=04 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 (BD: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 (BP: Vendor=0ea0 ProdID=2168 Rev= 2.00 (BS: Manufacturer=USB (BS: Product=Mass storage (BS: SerialNumber=142E1941D22BD5D6 (BC:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=
Re: [linux-usb-devel] Unable to read after closing usb-serial device
On Wed, 16 Feb 2005 11:09:03 +0800, Kharisma Esguerra <[EMAIL PROTECTED]> wrote: > It seems that after running a sample application (to send a command 10 > times), if you run the same application again, the application cannot > read from usb-serial. I have > to execute command "stty -F /dev/ttyUSB0" to be able to run the same > application and > read the responses. Maybe something is wrong with how I close the usb-serial > port. I saw similar problems, but 2.4.20 is way too ancient for me to remember what was fixed and what wasn't. I can only look at issues with stock kernel (not a Montavista one) and with a reasonably recent one. -- Pete --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Question about evdev
On Tue, Feb 15, 2005 at 06:40:37PM -0500, Dan Streetman wrote: > > Hi Vojtech, > > I have a question about the "contract" of the evdev interface... > > I have 2 touch screens, both USB. Both of them have drivers (hid-input > and mtouchusb) that provide ABS_X and ABS_Y coordinates to the input > subsystem and so I read those coordinates from userspace. > > However, one of the touch screens (ELO, via hid-input) reports coordinates > with the origin in the upper-left corner, i.e. touching the upper-left > corner of the screen reports 0,0. The other touch screen (3M, via > mtouchusb) reports coordinates with the origin at the bottom-left corner. > > So my question is, can an evdev app assume a specific origin? Yes, Linux input layer defines decreasing values to be the same as HID, that is up, far from the user, and left. Zero can be anywhere, but if only positive values are returned, it must be in the upper left corner. > Normal screen origin, i.e. upper-left, would make the most sense to > me. If so, it seems that mtouchusb should flip its Y coordinates > before sending to the input subsystem (which would be an easy patch of > course). It doesn't flip them while it should flip the Y coordinate. This is because many touchscreens have [0,0] in their bottom left corner by hardware, being in the 1st quadrant, which is considered most logical by many. I fixed it in my tree. > Or, can an app not rely on evdev's coordinate origin being > upper-left? Yes and no. You can rely that the driver will try to have [0,0] in the upper left corner, however this can be marred by the user turning the touchscreen 180 degrees on the monitor to get the cables on a more convenient side. This happens quite often. A complete matrix axis transformation is necessary then. -- Vojtech Pavlik SuSE Labs, SuSE CR --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
