[linux-usb-devel] [PATCH] Maxtor OneTouch button support for older drives
Hi! This small patch adds a device ID used by older Maxtor OneTouch drives (the ones with blue face-plate instead of the fancy silver one used in newer models). The button on those drives works well with the current driver. -- Antti Andreimann - Security Expert Using Linux since 1993 Member of ELUG since 29.01.2000 --- ./drivers/usb/storage/unusual_devs.h.orig 2005-11-14 06:35:03.0 +0200 +++ ./drivers/usb/storage/unusual_devs.h 2005-11-14 06:35:22.0 +0200 @@ -976,6 +976,11 @@ * */ #ifdef CONFIG_USB_STORAGE_ONETOUCH + UNUSUAL_DEV( 0x0d49, 0x7000, 0x, 0x, + Maxtor, + OneTouch External Harddrive, + US_SC_DEVICE, US_PR_DEVICE, onetouch_connect_input, + 0), UNUSUAL_DEV( 0x0d49, 0x7010, 0x, 0x, Maxtor, OneTouch External Harddrive,
Re: [linux-usb-devel] USB statistics
On Mon, 14 Nov 2005, Aras Vaichas wrote: I think they meant raw = bit errors, net = data did not arrive at all (within some timeout period). Bit errors would be reported somewhere and other errors would be handle by my test application at the highest level. The test department want to be able to zap the USB cable/plugs/sockets with a high voltage surge and then be able to see how the system copes with electrical discharges in the form of error statistics. These statistics then form the test results for the ESD immunity documentation. Something like that. Bit errors (actually packet or protocol errors) are not currently recorded anywhere, although they could be. Net errors would have to be determined by your test program, not by the kernel. Too true. I prefer to report that the data was either a) sent, b) not sent within a certain time. Much easier to perform from a shell script. Thank you for the thorough answers. It has helped greatly. You're welcome. Alan Stern --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] usbcore: central handling for host controllers that were reset during suspend/resume
Greg:
This patch (as515b) adds a routine to usbcore to simplify handling of host
controllers that lost power or were reset during suspend/resume. The new
core routine marks all the child devices of the root hub as NOTATTACHED
and tells khubd to disconnect the device structures as soon as possible.
Alan Stern
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
This patch removes the need for as600, since it will cause host controller
resets to remove all child devices whether or not CONFIG_USB_SUSPEND is
set.
Index: usb-2.6/drivers/usb/core/hub.c
===
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -1044,6 +1044,39 @@ void usb_set_device_state(struct usb_dev
EXPORT_SYMBOL(usb_set_device_state);
+#ifdef CONFIG_PM
+
+/**
+ * usb_root_hub_lost_power - called by HCD if the root hub lost Vbus power
+ * @rhdev: struct usb_device for the root hub
+ *
+ * The USB host controller driver calls this function when its root hub
+ * is resumed and Vbus power has been interrupted or the controller
+ * has been reset. The routine marks all the children of the root hub
+ * as NOTATTACHED and marks logical connect-change events on their ports.
+ */
+void usb_root_hub_lost_power(struct usb_device *rhdev)
+{
+ struct usb_hub *hub;
+ int port1;
+ unsigned long flags;
+
+ dev_warn(rhdev-dev, root hub lost power or was reset\n);
+ spin_lock_irqsave(device_state_lock, flags);
+ hub = hdev_to_hub(rhdev);
+ for (port1 = 1; port1 = rhdev-maxchild; ++port1) {
+ if (rhdev-children[port1 - 1]) {
+ recursively_mark_NOTATTACHED(
+ rhdev-children[port1 - 1]);
+ set_bit(port1, hub-change_bits);
+ }
+ }
+ spin_unlock_irqrestore(device_state_lock, flags);
+}
+EXPORT_SYMBOL_GPL(usb_root_hub_lost_power);
+
+#endif
+
static void choose_address(struct usb_device *udev)
{
int devnum;
Index: usb-2.6/drivers/usb/core/hcd.h
===
--- usb-2.6.orig/drivers/usb/core/hcd.h
+++ usb-2.6/drivers/usb/core/hcd.h
@@ -375,6 +375,7 @@ extern int usb_find_interface_driver (st
#ifdef CONFIG_PM
extern void usb_hcd_suspend_root_hub (struct usb_hcd *hcd);
extern void usb_hcd_resume_root_hub (struct usb_hcd *hcd);
+extern void usb_root_hub_lost_power (struct usb_device *rhdev);
extern int hcd_bus_suspend (struct usb_bus *bus);
extern int hcd_bus_resume (struct usb_bus *bus);
#else
Index: usb-2.6/drivers/usb/host/ehci-pci.c
===
--- usb-2.6.orig/drivers/usb/host/ehci-pci.c
+++ usb-2.6/drivers/usb/host/ehci-pci.c
@@ -251,7 +251,6 @@ static int ehci_pci_resume(struct usb_hc
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
unsignedport;
- struct usb_device *root = hcd-self.root_hub;
struct pci_dev *pdev = to_pci_dev(hcd-self.controller);
int retval = -EINVAL;
@@ -282,13 +281,7 @@ static int ehci_pci_resume(struct usb_hc
restart:
ehci_dbg(ehci, lost power, restarting\n);
- for (port = HCS_N_PORTS(ehci-hcs_params); port 0; ) {
- port--;
- if (!root-children [port])
- continue;
- usb_set_device_state(root-children[port],
- USB_STATE_NOTATTACHED);
- }
+ usb_root_hub_lost_power(hcd-self.root_hub);
/* Else reset, to cope with power loss or flush-to-storage
* style resume having let BIOS kick in during reboot.
Index: usb-2.6/drivers/usb/host/uhci-hcd.c
===
--- usb-2.6.orig/drivers/usb/host/uhci-hcd.c
+++ usb-2.6/drivers/usb/host/uhci-hcd.c
@@ -740,8 +740,12 @@ static int uhci_resume(struct usb_hcd *h
check_and_reset_hc(uhci);
configure_hc(uhci);
- if (uhci-rh_state == UHCI_RH_RESET)
+ if (uhci-rh_state == UHCI_RH_RESET) {
+
+ /* The controller had to be reset */
+ usb_root_hub_lost_power(hcd-self.root_hub);
suspend_rh(uhci, UHCI_RH_SUSPENDED);
+ }
spin_unlock_irq(uhci-lock);
Index: usb-2.6/drivers/usb/host/ohci-hcd.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-hcd.c
+++ usb-2.6/drivers/usb/host/ohci-hcd.c
@@ -791,7 +791,6 @@ static int ohci_restart (struct ohci_hcd
int temp;
int i;
struct urb_priv *priv;
- struct usb_device *root = ohci_to_hcd(ohci)-self.root_hub;
/* mark any devices gone, so they do nothing till khubd disconnects.
* recycle any live eds/tds (and urbs) right away.
@@ -800,11 +799,7 @@ static int ohci_restart (struct ohci_hcd
*/
[linux-usb-devel] [PATCH] dummy_hcd: rename variables
Greg:
The recent platform_device update has reintroduced into dummy_hcd.c the
dreaded dev-dev syndrome. This harkens back to when an earlier version
of that driver included the unforgettable line:
dev-dev.dev.driver_data = dev;
This patch (as602) renames the platform_device variables to pdev, in the
hope of reducing confusion.
Alan Stern
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/gadget/dummy_hcd.c
===
--- usb-2.6.orig/drivers/usb/gadget/dummy_hcd.c
+++ usb-2.6/drivers/usb/gadget/dummy_hcd.c
@@ -896,7 +896,7 @@ dummy_gadget_release (struct device *dev
#endif
}
-static int dummy_udc_probe (struct platform_device *dev)
+static int dummy_udc_probe (struct platform_device *pdev)
{
struct dummy*dum = the_controller;
int rc;
@@ -909,7 +909,7 @@ static int dummy_udc_probe (struct platf
dum-gadget.is_otg = (dummy_to_hcd(dum)-self.otg_port != 0);
strcpy (dum-gadget.dev.bus_id, gadget);
- dum-gadget.dev.parent = dev-dev;
+ dum-gadget.dev.parent = pdev-dev;
dum-gadget.dev.release = dummy_gadget_release;
rc = device_register (dum-gadget.dev);
if (rc 0)
@@ -919,47 +919,47 @@ static int dummy_udc_probe (struct platf
usb_bus_get (dummy_to_hcd (dum)-self);
#endif
- platform_set_drvdata (dev, dum);
+ platform_set_drvdata (pdev, dum);
device_create_file (dum-gadget.dev, dev_attr_function);
return rc;
}
-static int dummy_udc_remove (struct platform_device *dev)
+static int dummy_udc_remove (struct platform_device *pdev)
{
- struct dummy*dum = platform_get_drvdata (dev);
+ struct dummy*dum = platform_get_drvdata (pdev);
- platform_set_drvdata (dev, NULL);
+ platform_set_drvdata (pdev, NULL);
device_remove_file (dum-gadget.dev, dev_attr_function);
device_unregister (dum-gadget.dev);
return 0;
}
-static int dummy_udc_suspend (struct platform_device *dev, pm_message_t state)
+static int dummy_udc_suspend (struct platform_device *pdev, pm_message_t state)
{
- struct dummy*dum = platform_get_drvdata(dev);
+ struct dummy*dum = platform_get_drvdata(pdev);
- dev_dbg (dev-dev, %s\n, __FUNCTION__);
+ dev_dbg (pdev-dev, %s\n, __FUNCTION__);
spin_lock_irq (dum-lock);
dum-udc_suspended = 1;
set_link_state (dum);
spin_unlock_irq (dum-lock);
- dev-dev.power.power_state = state;
+ pdev-dev.power.power_state = state;
usb_hcd_poll_rh_status (dummy_to_hcd (dum));
return 0;
}
-static int dummy_udc_resume (struct platform_device *dev)
+static int dummy_udc_resume (struct platform_device *pdev)
{
- struct dummy*dum = platform_get_drvdata(dev);
+ struct dummy*dum = platform_get_drvdata(pdev);
- dev_dbg (dev-dev, %s\n, __FUNCTION__);
+ dev_dbg (pdev-dev, %s\n, __FUNCTION__);
spin_lock_irq (dum-lock);
dum-udc_suspended = 0;
set_link_state (dum);
spin_unlock_irq (dum-lock);
- dev-dev.power.power_state = PMSG_ON;
+ pdev-dev.power.power_state = PMSG_ON;
usb_hcd_poll_rh_status (dummy_to_hcd (dum));
return 0;
}
@@ -1899,14 +1899,14 @@ static const struct hc_driver dummy_hcd
.bus_resume = dummy_bus_resume,
};
-static int dummy_hcd_probe (struct platform_device *dev)
+static int dummy_hcd_probe (struct platform_device *pdev)
{
struct usb_hcd *hcd;
int retval;
- dev_info (dev-dev, %s, driver DRIVER_VERSION \n, driver_desc);
+ dev_info (pdev-dev, %s, driver DRIVER_VERSION \n, driver_desc);
- hcd = usb_create_hcd (dummy_hcd, dev-dev, dev-dev.bus_id);
+ hcd = usb_create_hcd (dummy_hcd, pdev-dev, pdev-dev.bus_id);
if (!hcd)
return -ENOMEM;
the_controller = hcd_to_dummy (hcd);
@@ -1919,34 +1919,34 @@ static int dummy_hcd_probe (struct platf
return retval;
}
-static int dummy_hcd_remove (struct platform_device *dev)
+static int dummy_hcd_remove (struct platform_device *pdev)
{
struct usb_hcd *hcd;
- hcd = platform_get_drvdata (dev);
+ hcd = platform_get_drvdata (pdev);
usb_remove_hcd (hcd);
usb_put_hcd (hcd);
the_controller = NULL;
return 0;
}
-static int dummy_hcd_suspend (struct platform_device *dev, pm_message_t state)
+static int dummy_hcd_suspend (struct platform_device *pdev, pm_message_t state)
{
struct usb_hcd *hcd;
- dev_dbg (dev-dev, %s\n, __FUNCTION__);
- hcd = platform_get_drvdata (dev);
+ dev_dbg (pdev-dev, %s\n, __FUNCTION__);
+ hcd = platform_get_drvdata (pdev);
hcd-state = HC_STATE_SUSPENDED;
return 0;
}
-static int dummy_hcd_resume (struct platform_device *dev)
+static int
[linux-usb-devel] USB stack hangs after sporadic disconnect
Hi, on a VIA Eden box, I'm getting sporadic USB disconnects after longer operation times. Typically, there is no USB load when it disconnects. The kernel output is like this: kernel: hub 4-0:1.0: state 5 ports 6 chg evt 0008 kernel: ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC CONNECT kernel: hub 4-0:1.0: port 3, status 0501, change 0003, 480 Mb/s kernel: usb 4-3: USB disconnect, address 2 kernel: usb 4-3: usb_disable_device nuking all URBs kernel: ehci_hcd :00:10.3: shutdown urb c633cc20 pipe 8280 ep0in kernel: usb 4-3: hcd_unlink_urb c633cc20 fail -16 Attached are either a rt2570-based USB WLAN stick (via native driver) or a LinkSys WUSB54G WLAN adapter (via ndiswrapper). Both fail, and in both cases the USB subsystem locks up in some nasty way (deadlock, rest of system still alive) so that no resetting/unloading of the involved drivers is possible. Only a hard reboot helps. I'm watching this effect for quite a while now, so far with 2.6.8 kernels, now also with a recent 2.6.14.2. I could live with the fact that my hardware may have some sporadic problems and I have to reset/reload parts of my system from time to time; it's easy to setup a watchdog script for this. But the hanging USB stack prevents this. Any ideas? Any additional information required? I could instrument the code and reproduce this if it helps to track the reason down. Thanks in advance, Jan PS: Please CC, I'm not subscribed. signature.asc Description: OpenPGP digital signature
[linux-usb-devel] [PATCH] Make usbdevice_fs.h (again) useable from userspace
Make usbdevice_fs.h (again) useable from userspace
If we have CONFIG_COMPAT enabled, then userspace programs using
usbdevice_fs.h won't compile anymore.
Signed-off-by: Harald Welte [EMAIL PROTECTED]
---
commit 17c6b20f34d9d68918346af2a2eb6433b09af0e3
tree 397763d1e6776163d45d97702a54d352295940c2
parent b3d70298da3a00f29dd82cf16c1f13407ad2ac09
author Harald Welte [EMAIL PROTECTED] Mon, 14 Nov 2005 18:34:23 +0100
committer Harald Welte [EMAIL PROTECTED] Mon, 14 Nov 2005 18:34:23 +0100
include/linux/usbdevice_fs.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/usbdevice_fs.h b/include/linux/usbdevice_fs.h
--- a/include/linux/usbdevice_fs.h
+++ b/include/linux/usbdevice_fs.h
@@ -123,6 +123,7 @@ struct usbdevfs_hub_portinfo {
char port [127];/* e.g. port 3 connects to device 27 */
};
+#ifdef __KERNEL__
#ifdef CONFIG_COMPAT
#include linux/compat.h
struct usbdevfs_urb32 {
@@ -147,6 +148,7 @@ struct usbdevfs_ioctl32 {
compat_caddr_t data;
};
#endif
+#endif
#define USBDEVFS_CONTROL _IOWR('U', 0, struct usbdevfs_ctrltransfer)
#define USBDEVFS_BULK _IOWR('U', 2, struct usbdevfs_bulktransfer)
--
- Harald Welte [EMAIL PROTECTED] http://gnumonks.org/
Privacy in residential applications is a desirable marketing option.
(ETSI EN 300 175-7 Ch. A6)
pgpgWHub7dugB.pgp
Description: PGP signature
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
On Mon, Nov 14, 2005 at 06:35:22PM +0100, Jan Kiszka wrote: Hi, on a VIA Eden box, I'm getting sporadic USB disconnects after longer operation times. Typically, there is no USB load when it disconnects. The kernel output is like this: kernel: hub 4-0:1.0: state 5 ports 6 chg evt 0008 kernel: ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC CONNECT kernel: hub 4-0:1.0: port 3, status 0501, change 0003, 480 Mb/s kernel: usb 4-3: USB disconnect, address 2 kernel: usb 4-3: usb_disable_device nuking all URBs kernel: ehci_hcd :00:10.3: shutdown urb c633cc20 pipe 8280 ep0in kernel: usb 4-3: hcd_unlink_urb c633cc20 fail -16 Attached are either a rt2570-based USB WLAN stick (via native driver) or a LinkSys WUSB54G WLAN adapter (via ndiswrapper). Both fail, and in both cases the USB subsystem locks up in some nasty way (deadlock, rest of system still alive) so that no resetting/unloading of the involved drivers is possible. Only a hard reboot helps. I'm watching this effect for quite a while now, so far with 2.6.8 kernels, now also with a recent 2.6.14.2. If you are using ndiswrapper, there's nothing we can do to help you, sorry. What driver controls the rt2570-based USB WLAN device, usbnet? thanks, greg k-h --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] Make usbdevice_fs.h (again) useable from userspace
On Mon, 2005-11-14 at 18:37 +0100, Harald Welte wrote: Make usbdevice_fs.h (again) useable from userspace If we have CONFIG_COMPAT enabled, then userspace programs using usbdevice_fs.h won't compile anymore. how does the userspace application set CONFIG_COMPAT?? --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch] OHCI lh7a404 platform device conversion fixup
Fix an error in the OHCI lh7a404 driver after the platform device
conversion.
Signed-off-by: Richard Purdie [EMAIL PROTECTED]
Index: linux-2.6.15-rc1/drivers/usb/host/ohci-lh7a404.c
===
--- linux-2.6.15-rc1.orig/drivers/usb/host/ohci-lh7a404.c 2005-11-12
01:43:36.0 +
+++ linux-2.6.15-rc1/drivers/usb/host/ohci-lh7a404.c2005-11-14
17:41:14.0 +
@@ -219,7 +219,7 @@
static int ohci_hcd_lh7a404_drv_remove(struct platform_device *pdev)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
usb_hcd_lh7a404_remove(hcd, pdev);
return 0;
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
Greg KH wrote: On Mon, Nov 14, 2005 at 06:35:22PM +0100, Jan Kiszka wrote: Hi, on a VIA Eden box, I'm getting sporadic USB disconnects after longer operation times. Typically, there is no USB load when it disconnects. The kernel output is like this: kernel: hub 4-0:1.0: state 5 ports 6 chg evt 0008 kernel: ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC CONNECT kernel: hub 4-0:1.0: port 3, status 0501, change 0003, 480 Mb/s kernel: usb 4-3: USB disconnect, address 2 kernel: usb 4-3: usb_disable_device nuking all URBs kernel: ehci_hcd :00:10.3: shutdown urb c633cc20 pipe 8280 ep0in kernel: usb 4-3: hcd_unlink_urb c633cc20 fail -16 Attached are either a rt2570-based USB WLAN stick (via native driver) or a LinkSys WUSB54G WLAN adapter (via ndiswrapper). Both fail, and in both cases the USB subsystem locks up in some nasty way (deadlock, rest of system still alive) so that no resetting/unloading of the involved drivers is possible. Only a hard reboot helps. I'm watching this effect for quite a while now, so far with 2.6.8 kernels, now also with a recent 2.6.14.2. If you are using ndiswrapper, there's nothing we can do to help you, sorry. We do not need to raise a discussion about this topic here. I only mentioned ndiswrapper and the WUSB54G to express that this issues does not seem to be high-level driver related. I always thought it would be a ndiswrapper or LinkSys Windows driver issue until I bought this second device. What driver controls the rt2570-based USB WLAN device, usbnet? http://sourceforge.net/projects/rt2400, the stable rt2570 driver Thanks for the quick reply, Jan signature.asc Description: OpenPGP digital signature
Re: [linux-usb-devel] [PATCH] dummy_hcd: rename variables
On Monday 14 November 2005 9:16 am, Alan Stern wrote: The recent platform_device update has reintroduced into dummy_hcd.c the dreaded dev-dev syndrome. This harkens back to when an earlier version of that driver included the unforgettable line: dev-dev.dev.driver_data = dev; This patch (as602) renames the platform_device variables to pdev, in the hope of reducing confusion. Surely it would be simpler if everything were just called bruce? ;) --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
Greg KH wrote: On Mon, Nov 14, 2005 at 06:54:17PM +0100, Jan Kiszka wrote: Greg KH wrote: On Mon, Nov 14, 2005 at 06:35:22PM +0100, Jan Kiszka wrote: Hi, on a VIA Eden box, I'm getting sporadic USB disconnects after longer operation times. Typically, there is no USB load when it disconnects. The kernel output is like this: kernel: hub 4-0:1.0: state 5 ports 6 chg evt 0008 kernel: ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC CONNECT kernel: hub 4-0:1.0: port 3, status 0501, change 0003, 480 Mb/s kernel: usb 4-3: USB disconnect, address 2 kernel: usb 4-3: usb_disable_device nuking all URBs kernel: ehci_hcd :00:10.3: shutdown urb c633cc20 pipe 8280 ep0in kernel: usb 4-3: hcd_unlink_urb c633cc20 fail -16 Attached are either a rt2570-based USB WLAN stick (via native driver) or a LinkSys WUSB54G WLAN adapter (via ndiswrapper). Both fail, and in both cases the USB subsystem locks up in some nasty way (deadlock, rest of system still alive) so that no resetting/unloading of the involved drivers is possible. Only a hard reboot helps. I'm watching this effect for quite a while now, so far with 2.6.8 kernels, now also with a recent 2.6.14.2. If you are using ndiswrapper, there's nothing we can do to help you, sorry. We do not need to raise a discussion about this topic here. That's fine, just letting you know. I only mentioned ndiswrapper and the WUSB54G to express that this issues does not seem to be high-level driver related. I always thought it would be a ndiswrapper or LinkSys Windows driver issue until I bought this second device. What driver controls the rt2570-based USB WLAN device, usbnet? http://sourceforge.net/projects/rt2400, the stable rt2570 driver I suggest you ask the authors of this driver, not much we can do here either :( Now if you have a problem with an in-kernel driver, then we can help. Well, I must say that this degree of cooperation from an Open Source project is rather new to me. Did I violate your policy by posting to devel directly? Than sorry, just tell me. All I am asking for are some hints what may go wrong in my case, what the messages e.g. mean. If you are not /able/ to debug this problem in theory (likely I will have to do this on my hardware in real anyway), then please explain why you can exclude a bug in the USB stack. Otherwise, with my currently limited detail knowledge of the involved components, I may easily end up being bumped between both projects. Jan signature.asc Description: OpenPGP digital signature
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
On Mon, Nov 14, 2005 at 07:36:13PM +0100, Jan Kiszka wrote: Greg KH wrote: On Mon, Nov 14, 2005 at 06:54:17PM +0100, Jan Kiszka wrote: Greg KH wrote: On Mon, Nov 14, 2005 at 06:35:22PM +0100, Jan Kiszka wrote: Hi, on a VIA Eden box, I'm getting sporadic USB disconnects after longer operation times. Typically, there is no USB load when it disconnects. The kernel output is like this: kernel: hub 4-0:1.0: state 5 ports 6 chg evt 0008 kernel: ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC CONNECT kernel: hub 4-0:1.0: port 3, status 0501, change 0003, 480 Mb/s kernel: usb 4-3: USB disconnect, address 2 kernel: usb 4-3: usb_disable_device nuking all URBs kernel: ehci_hcd :00:10.3: shutdown urb c633cc20 pipe 8280 ep0in kernel: usb 4-3: hcd_unlink_urb c633cc20 fail -16 Attached are either a rt2570-based USB WLAN stick (via native driver) or a LinkSys WUSB54G WLAN adapter (via ndiswrapper). Both fail, and in both cases the USB subsystem locks up in some nasty way (deadlock, rest of system still alive) so that no resetting/unloading of the involved drivers is possible. Only a hard reboot helps. I'm watching this effect for quite a while now, so far with 2.6.8 kernels, now also with a recent 2.6.14.2. If you are using ndiswrapper, there's nothing we can do to help you, sorry. We do not need to raise a discussion about this topic here. That's fine, just letting you know. I only mentioned ndiswrapper and the WUSB54G to express that this issues does not seem to be high-level driver related. I always thought it would be a ndiswrapper or LinkSys Windows driver issue until I bought this second device. What driver controls the rt2570-based USB WLAN device, usbnet? http://sourceforge.net/projects/rt2400, the stable rt2570 driver I suggest you ask the authors of this driver, not much we can do here either :( Now if you have a problem with an in-kernel driver, then we can help. Well, I must say that this degree of cooperation from an Open Source project is rather new to me. Did I violate your policy by posting to devel directly? Than sorry, just tell me. No, no policy violation, it's just that we really have no idea what is going on in drivers that we don't have access too, that's all. All I am asking for are some hints what may go wrong in my case, what the messages e.g. mean. If you are not /able/ to debug this problem in theory (likely I will have to do this on my hardware in real anyway), then please explain why you can exclude a bug in the USB stack. I can't exclude such a bug. But I really think it's a bug in the lower level driver, as this problem doesn't seem to be reported for any other usb driver so far that I have seen. Otherwise, with my currently limited detail knowledge of the involved components, I may easily end up being bumped between both projects. If the rt2400 people push you back here, with information showing that it is a USB core problem, we will be glad to help you out. Otherwise, how are we supposed to be able to help (given previously mentioned lack of source to rely on.) I'm not trying to pass you on to someone else because I don't want to help, I'm only trying to point you to who is in the best position to help you out with your problem. thanks, greg k-h --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] Make usbdevice_fs.h (again) useable from userspace
On Mon, Nov 14, 2005 at 06:45:27PM +0100, Arjan van de Ven wrote: On Mon, 2005-11-14 at 18:37 +0100, Harald Welte wrote: Make usbdevice_fs.h (again) useable from userspace If we have CONFIG_COMPAT enabled, then userspace programs using usbdevice_fs.h won't compile anymore. how does the userspace application set CONFIG_COMPAT?? duh. good question. Seems like the application was broken by somehow including config.h, so we can safely ignore this. Sorry for the noise. -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgphe2UtFvOtI.pgp Description: PGP signature
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
On Mon, 14 Nov 2005, Jan Kiszka wrote: Hi, on a VIA Eden box, I'm getting sporadic USB disconnects after longer operation times. Typically, there is no USB load when it disconnects. The kernel output is like this: kernel: hub 4-0:1.0: state 5 ports 6 chg evt 0008 kernel: ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC CONNECT kernel: hub 4-0:1.0: port 3, status 0501, change 0003, 480 Mb/s kernel: usb 4-3: USB disconnect, address 2 kernel: usb 4-3: usb_disable_device nuking all URBs kernel: ehci_hcd :00:10.3: shutdown urb c633cc20 pipe 8280 ep0in kernel: usb 4-3: hcd_unlink_urb c633cc20 fail -16 Attached are either a rt2570-based USB WLAN stick (via native driver) or a LinkSys WUSB54G WLAN adapter (via ndiswrapper). Both fail, and in both cases the USB subsystem locks up in some nasty way (deadlock, rest of system still alive) so that no resetting/unloading of the involved drivers is possible. Only a hard reboot helps. I'm watching this effect for quite a while now, so far with 2.6.8 kernels, now also with a recent 2.6.14.2. I could live with the fact that my hardware may have some sporadic problems and I have to reset/reload parts of my system from time to time; it's easy to setup a watchdog script for this. But the hanging USB stack prevents this. Any ideas? Any additional information required? I could instrument the code and reproduce this if it helps to track the reason down. I can give you the kernel developer's point of view. According to those log messages, there was an interruption of the USB connection which made it look as though device 4-3 had been physically unplugged. This could be caused by device problems, cable problems, controller problems, or an actual disconnect. The -16 (-EBUSY) message at the end is just an unimportant warning; it means that the USB core failed to unlink an URB because something else (probably the device driver) had already unlinked it. The hang is almost certainly caused by the device's driver. Apparently its disconnect method is not returning. Since that routine is called by the main hub driver and with a lock held, this means that most other major activities of the USB stack will be blocked as well. To get more information when you see these messages in the log and things are hung up, get a stack trace with Alt-SysRq-T. The entry for khubd is of particular interest; others may be important also depending on the driver. Alan Stern --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
On Monday 14 November 2005 9:35 am, Jan Kiszka wrote:
ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC
CONNECT
Translation: the root hub spontaneously disconnected. There are such
reports, which are as far as I can tell always with VIA hardware. I have
no idea what causes them.
The stack hanging is a different issue:
usb 4-3: hcd_unlink_urb c633cc20 fail -16
EBUSY status code happens in a few cases, and in this path I'd suspect
it means the URB is already being returned. Could you try the patch
I've attached, to see if it prints anything?
- Dave
Index: g26/drivers/usb/host/ehci-q.c
===
--- g26.orig/drivers/usb/host/ehci-q.c 2005-11-06 08:29:00.0 -0800
+++ g26/drivers/usb/host/ehci-q.c 2005-11-14 11:36:45.0 -0800
@@ -784,6 +784,8 @@ static void qh_link_async (struct ehci_h
if (!head-qh_next.qh) {
u32 cmd = readl (ehci-regs-command);
+WARN_ON(ehci-reclaim);
+
if (!(cmd CMD_ASE)) {
/* in case a clear of CMD_ASE didn't take yet */
(void) handshake (ehci-regs-status, STS_ASS, 0, 150);
[linux-usb-devel] [patch 00/12] USB patches for 2.6.15-rc1
Here are a few USB patches against your latest git tree, they have all been in the past few -mm releases just fine. They fix some build bugs, add some new device ids, and add a new simple usb-serial driver. thanks, greg k-h --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 01/12] USB: fix build breakage in dummy_hcd.c
From: Greg Kroah-Hartman [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- drivers/usb/gadget/dummy_hcd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- gregkh-2.6.orig/drivers/usb/gadget/dummy_hcd.c +++ gregkh-2.6/drivers/usb/gadget/dummy_hcd.c @@ -944,7 +944,7 @@ static int dummy_udc_suspend (struct pla set_link_state (dum); spin_unlock_irq (dum-lock); - dev-power.power_state = state; + dev-dev.power.power_state = state; usb_hcd_poll_rh_status (dummy_to_hcd (dum)); return 0; } @@ -1904,7 +1904,7 @@ static int dummy_hcd_probe (struct platf struct usb_hcd *hcd; int retval; - dev_info (dev, %s, driver DRIVER_VERSION \n, driver_desc); + dev_info(dev-dev, %s, driver DRIVER_VERSION \n, driver_desc); hcd = usb_create_hcd (dummy_hcd, dev-dev, dev-dev.bus_id); if (!hcd) -- --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 04/12] USB: wacom tablet driver update
From: Ping Cheng [EMAIL PROTECTED]
This patch adds support for Graphire4, Cintiq 710, Intuos3 6x11, etc. and
report Device IDs.
Signed-off-by: Ping Cheng [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/usb/input/wacom.c | 133 ++
1 file changed, 110 insertions(+), 23 deletions(-)
--- gregkh-2.6.orig/drivers/usb/input/wacom.c
+++ gregkh-2.6/drivers/usb/input/wacom.c
@@ -52,8 +52,10 @@
*v1.30.1 (pi) - Added Graphire3 support
* v1.40 (pc) - Add support for several new devices, fix eraser reporting,
...
* v1.43 (pc) - Added support for Cintiq 21UX
- - Fixed a Graphire bug
- - Merged wacom_intuos3_irq into wacom_intuos_irq
+ *- Fixed a Graphire bug
+ *- Merged wacom_intuos3_irq into wacom_intuos_irq
+ * v1.44 (pc) - Added support for Graphire4, Cintiq 710, Intuos3 6x11, etc.
+ *- Report Device IDs
*/
/*
@@ -76,7 +78,7 @@
/*
* Version Information
*/
-#define DRIVER_VERSION v1.43
+#define DRIVER_VERSION v1.44
#define DRIVER_AUTHOR Vojtech Pavlik [EMAIL PROTECTED]
#define DRIVER_DESC USB Wacom Graphire and Wacom Intuos tablet driver
#define DRIVER_LICENSE GPL
@@ -86,10 +88,14 @@ MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE(DRIVER_LICENSE);
#define USB_VENDOR_ID_WACOM0x056a
+#define STYLUS_DEVICE_ID 0x02
+#define CURSOR_DEVICE_ID 0x06
+#define ERASER_DEVICE_ID 0x0A
enum {
PENPARTNER = 0,
GRAPHIRE,
+ G4,
PL,
INTUOS,
INTUOS3,
@@ -116,6 +122,7 @@ struct wacom {
struct urb *irq;
struct wacom_features *features;
int tool[2];
+ int id[2];
__u32 serial[2];
char phys[32];
};
@@ -136,7 +143,7 @@ static void wacom_pl_irq(struct urb *urb
struct wacom *wacom = urb-context;
unsigned char *data = wacom-data;
struct input_dev *dev = wacom-dev;
- int prox, pressure;
+ int prox, pressure, id;
int retval;
switch (urb-status) {
@@ -163,6 +170,7 @@ static void wacom_pl_irq(struct urb *urb
input_regs(dev, regs);
+ id = ERASER_DEVICE_ID;
if (prox) {
pressure = (signed char)((data[7] 1) | ((data[4] 2) 1));
@@ -177,11 +185,15 @@ static void wacom_pl_irq(struct urb *urb
* an out of proximity for previous tool then a in for new tool.
*/
if (!wacom-tool[0]) {
- /* Going into proximity select tool */
- wacom-tool[1] = (data[4] 0x20)? BTN_TOOL_RUBBER :
BTN_TOOL_PEN;
+ /* Eraser bit set for DTF */
+ if (data[1] 0x10)
+ wacom-tool[1] = BTN_TOOL_RUBBER;
+ else
+ /* Going into proximity select tool */
+ wacom-tool[1] = (data[4] 0x20) ?
BTN_TOOL_RUBBER : BTN_TOOL_PEN;
} else {
/* was entered with stylus2 pressed */
- if (wacom-tool[1] == BTN_TOOL_RUBBER !(data[4]
0x20) ) {
+ if (wacom-tool[1] == BTN_TOOL_RUBBER !(data[4]
0x20)) {
/* report out proximity for previous tool */
input_report_key(dev, wacom-tool[1], 0);
input_sync(dev);
@@ -192,8 +204,9 @@ static void wacom_pl_irq(struct urb *urb
if (wacom-tool[1] != BTN_TOOL_RUBBER) {
/* Unknown tool selected default to pen tool */
wacom-tool[1] = BTN_TOOL_PEN;
+ id = STYLUS_DEVICE_ID;
}
- input_report_key(dev, wacom-tool[1], prox); /* report in
proximity for tool */
+ input_report_key(dev, wacom-tool[1], id); /* report in
proximity for tool */
input_report_abs(dev, ABS_X, data[3] | (data[2] 7) |
((data[1] 0x03) 14));
input_report_abs(dev, ABS_Y, data[6] | (data[5] 7) |
((data[4] 0x03) 14));
input_report_abs(dev, ABS_PRESSURE, pressure);
@@ -250,10 +263,10 @@ static void wacom_ptu_irq(struct urb *ur
input_regs(dev, regs);
if (data[1] 0x04) {
- input_report_key(dev, BTN_TOOL_RUBBER, data[1] 0x20);
+ input_report_key(dev, BTN_TOOL_RUBBER, (data[1] 0x20) ?
ERASER_DEVICE_ID : 0);
input_report_key(dev, BTN_TOUCH, data[1] 0x08);
} else {
- input_report_key(dev, BTN_TOOL_PEN, data[1] 0x20);
+ input_report_key(dev, BTN_TOOL_PEN, (data[1] 0x20) ?
STYLUS_DEVICE_ID : 0);
input_report_key(dev, BTN_TOUCH, data[1] 0x01);
}
input_report_abs(dev, ABS_X, le16_to_cpu(*(__le16 *) data[2]));
@@ -299,7 +312,7 @@ static void
[linux-usb-devel] [patch 06/12] USB: Delete leftovers from bluetty driver
From: Marcel Holtmann [EMAIL PROTECTED]
This patch deletes the bluetooth.txt help file of the bluetty driver and
hands over its major device nodes for character devices to the RFCOMM TTY
implementation of the Bluetooth subsystem.
Signed-off-by: Marcel Holtmann [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
Documentation/devices.txt | 12 +-
Documentation/usb/bluetooth.txt | 44
2 files changed, 6 insertions(+), 50 deletions(-)
--- usb-2.6.orig/Documentation/devices.txt
+++ usb-2.6/Documentation/devices.txt
@@ -2903,14 +2903,14 @@ Your cooperation is appreciated.
196 = /dev/dvb/adapter3/video0first video decoder of fourth
card
-216 char USB BlueTooth devices
- 0 = /dev/ttyUB0 First USB BlueTooth device
- 1 = /dev/ttyUB1 Second USB BlueTooth device
+216 char Bluetooth RFCOMM TTY devices
+ 0 = /dev/rfcomm0 First Bluetooth RFCOMM TTY
device
+ 1 = /dev/rfcomm1 Second Bluetooth RFCOMM TTY
device
...
-217 char USB BlueTooth devices (alternate devices)
- 0 = /dev/cuub0Callout device for ttyUB0
- 1 = /dev/cuub1Callout device for ttyUB1
+217 char Bluetooth RFCOMM TTY devices (alternate devices)
+ 0 = /dev/curf0Callout device for rfcomm0
+ 1 = /dev/curf1Callout device for rfcomm1
...
218 char The Logical Company bus Unibus/Qbus adapters
--- usb-2.6.orig/Documentation/usb/bluetooth.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-INTRODUCTION
-
- The USB Bluetooth driver supports any USB Bluetooth device.
- It currently works well with the Linux USB Bluetooth stack from Axis
- (available at http://developer.axis.com/software/bluetooth/ ) and
- has been rumored to work with other Linux USB Bluetooth stacks.
-
-
-CONFIGURATION
-
- Currently the driver can handle up to 256 different USB Bluetooth
- devices at once.
-
- If you are not using devfs:
-The major number that the driver uses is 216 so to use the driver,
-create the following nodes:
- mknod /dev/ttyUB0 c 216 0
- mknod /dev/ttyUB1 c 216 1
- mknod /dev/ttyUB2 c 216 2
- mknod /dev/ttyUB3 c 216 3
- .
- .
- .
- mknod /dev/ttyUB254 c 216 254
- mknod /dev/ttyUB255 c 216 255
-
- If you are using devfs:
-The devices supported by this driver will show up as
-/dev/usb/ttub/{0,1,...}
-
- When the device is connected and recognized by the driver, the driver
- will print to the system log, which node the device has been bound to.
-
-
-CONTACT:
-
- If anyone has any problems using this driver, please contact me, or
- join the Linux-USB mailing list (information on joining the mailing
- list, as well as a link to its searchable archive is at
- http://www.linux-usb.org/ )
-
-
-Greg Kroah-Hartman
[EMAIL PROTECTED]
--
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 03/12] USB: add new wacom devices to usb hid-core list
From: Ping Cheng [EMAIL PROTECTED]
This patch adds support for Graphire4, Cintiq 710, Intuos3 6x11, etc.
Signed-off-by: Ping Cheng [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/usb/input/hid-core.c | 12
1 file changed, 12 insertions(+)
--- gregkh-2.6.orig/drivers/usb/input/hid-core.c
+++ gregkh-2.6/drivers/usb/input/hid-core.c
@@ -1318,6 +1318,7 @@ void hid_init_reports(struct hid_device
#define USB_DEVICE_ID_WACOM_PTU0x0003
#define USB_DEVICE_ID_WACOM_INTUOS30x00B0
#define USB_DEVICE_ID_WACOM_CINTIQ 0x003F
+#define USB_DEVICE_ID_WACOM_DTF 0x00C0
#define USB_VENDOR_ID_ACECAD 0x0460
#define USB_DEVICE_ID_ACECAD_FLAIR 0x0004
@@ -1524,6 +1525,9 @@ static struct hid_blacklist {
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_PL + 3, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_PL + 4, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_PL + 5, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_PL + 7, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_PL + 8, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_PL + 9, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_INTUOS2 + 1,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_INTUOS2 + 2,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_INTUOS2 + 3,
HID_QUIRK_IGNORE },
@@ -1531,11 +1535,19 @@ static struct hid_blacklist {
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_INTUOS2 + 5,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_INTUOS2 + 7,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_VOLITO, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_VOLITO + 1, HID_QUIRK_IGNORE
},
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_VOLITO + 2, HID_QUIRK_IGNORE
},
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_VOLITO + 3, HID_QUIRK_IGNORE
},
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_VOLITO + 4, HID_QUIRK_IGNORE
},
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_GRAPHIRE + 5,
HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_GRAPHIRE + 6,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_PTU, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_INTUOS3, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_INTUOS3 + 1,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_INTUOS3 + 2,
HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_INTUOS3 + 5,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_CINTIQ, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_DTF, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_4_PHIDGETSERVO_20,
HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_1_PHIDGETSERVO_20,
HID_QUIRK_IGNORE },
--
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 05/12] USB: fix 'unused variable' warning
From: Dmitry Torokhov [EMAIL PROTECTED]
USB: fix 'unused variable' warning
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
drivers/usb/core/message.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- gregkh-2.6.orig/drivers/usb/core/message.c 2005-11-02 09:25:03.0
-0800
+++ gregkh-2.6/drivers/usb/core/message.c 2005-11-02 10:28:05.0
-0800
@@ -1457,12 +1457,11 @@
*/
for (i = 0; i nintf; ++i) {
struct usb_interface *intf = cp-interface[i];
- struct usb_host_interface *alt = intf-cur_altsetting;
dev_dbg (dev-dev,
adding %s (config #%d, interface %d)\n,
intf-dev.bus_id, configuration,
- alt-desc.bInterfaceNumber);
+ intf-cur_altsetting-desc.bInterfaceNumber);
ret = device_add (intf-dev);
if (ret != 0) {
dev_err(dev-dev,
--
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 02/12] USB Serial: rename ChangeLog.old
From: Greg Kroah-Hartman [EMAIL PROTECTED] People are complaining about a .old file in the tree. So rename drivers/usb/serial/ChangeLog.old to ChangeLog.history. Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] drivers/usb/serial/ChangeLog.history | 730 +++ drivers/usb/serial/ChangeLog.old | 730 --- 2 files changed, 730 insertions(+), 730 deletions(-) --- /dev/null 1970-01-01 00:00:00.0 + +++ gregkh-2.6/drivers/usb/serial/ChangeLog.history 2005-11-12 20:51:52.0 -0800 @@ -0,0 +1,730 @@ +This is the contents of some of the drivers/usb/serial/ files that had old +changelog comments. They were quite old, and out of date, and we don't keep +them anymore, so I've put them here, away from the source files, in case +people still care to see them. + +- Greg Kroah-Hartman [EMAIL PROTECTED] October 20, 2005 + +--- +usb-serial.h Change Log comments: + + (03/26/2002) gkh + removed the port-tty check from port_paranoia_check() due to serial + consoles not having a tty device assigned to them. + + (12/03/2001) gkh + removed active from the port structure. + added documentation to the usb_serial_device_type structure + + (10/10/2001) gkh + added vendor and product to serial structure. Needed to determine device + owner when the device is disconnected. + + (05/30/2001) gkh + added sem to port structure and removed port_lock + + (10/05/2000) gkh + Added interrupt_in_endpointAddress and bulk_in_endpointAddress to help + fix bug with urb-dev not being set properly, now that the usb core + needs it. + + (09/11/2000) gkh + Added usb_serial_debug_data function to help get rid of #DEBUG in the + drivers. + + (08/28/2000) gkh + Added port_lock to port structure. + + (08/08/2000) gkh + Added open_count to port structure. + + (07/23/2000) gkh + Added bulk_out_endpointAddress to port structure. + + (07/19/2000) gkh, pberger, and borchers + Modifications to allow usb-serial drivers to be modules. + +--- +usb-serial.c Change Log comments: + + (12/10/2002) gkh + Split the ports off into their own struct device, and added a + usb-serial bus driver. + + (11/19/2002) gkh + removed a few #ifdefs for the generic code and cleaned up the failure + logic in initialization. + + (10/02/2002) gkh + moved the console code to console.c and out of this file. + + (06/05/2002) gkh + moved location of startup() call in serial_probe() until after all + of the port information and endpoints are initialized. This makes + things easier for some drivers. + + (04/10/2002) gkh + added serial_read_proc function which creates a + /proc/tty/driver/usb-serial file. + + (03/27/2002) gkh + Got USB serial console code working properly and merged into the main + version of the tree. Thanks to Randy Dunlap for the initial version + of this code, and for pushing me to finish it up. + The USB serial console works with any usb serial driver device. + + (03/21/2002) gkh + Moved all manipulation of port-open_count into the core. Now the + individual driver's open and close functions are called only when the + first open() and last close() is called. Making the drivers a bit + smaller and simpler. + Fixed a bug if a driver didn't have the owner field set. + + (02/26/2002) gkh + Moved all locking into the main serial_* functions, instead of having + the individual drivers have to grab the port semaphore. This should + reduce races. + Reworked the MOD_INC logic a bit to always increment and decrement, even + if the generic driver is being used. + + (10/10/2001) gkh + usb_serial_disconnect() now sets the serial-dev pointer is to NULL to + help prevent child drivers from accessing the device since it is now + gone. + + (09/13/2001) gkh + Moved generic driver initialize after we have registered with the USB + core. Thanks to Randy Dunlap for pointing this problem out. + + (07/03/2001) gkh + Fixed module paramater size. Thanks to John Brockmeyer for the pointer. + Fixed vendor and product getting defined through the MODULE_PARM macro + if the Generic driver wasn't compiled in. + Fixed problem with generic_shutdown() not being called for drivers that + don't have a shutdown() function. + + (06/06/2001) gkh + added evil hack that is needed for the prolific pl2303 device due to the + crazy way its endpoints are set up. + + (05/30/2001) gkh + switched from using spinlock to a semaphore, which fixes lots of problems. + + (04/08/2001) gb + Identify version on module load. + + 2001_02_05 gkh + Fixed buffer
[linux-usb-devel] [patch 07/12] usbfs: usbfs_dir_inode_operations cleanup
From: OGAWA Hirofumi [EMAIL PROTECTED]
This patch is just cleanup.
Signed-off-by: OGAWA Hirofumi [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/usb/core/inode.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
--- gregkh-2.6.orig/drivers/usb/core/inode.c2005-11-02 09:25:03.0
-0800
+++ gregkh-2.6/drivers/usb/core/inode.c 2005-11-02 12:02:53.0 -0800
@@ -46,7 +46,6 @@
static struct super_operations usbfs_ops;
static struct file_operations default_file_operations;
-static struct inode_operations usbfs_dir_inode_operations;
static struct vfsmount *usbfs_mount;
static int usbfs_mount_count; /* = 0 */
static int ignore_mount = 0;
@@ -262,7 +261,7 @@
inode-i_fop = default_file_operations;
break;
case S_IFDIR:
- inode-i_op = usbfs_dir_inode_operations;
+ inode-i_op = simple_dir_inode_operations;
inode-i_fop = simple_dir_operations;
/* directory inodes start off with i_nlink == 2 (for
. entry) */
@@ -417,10 +416,6 @@
.llseek = default_file_lseek,
};
-static struct inode_operations usbfs_dir_inode_operations = {
- .lookup = simple_lookup,
-};
-
static struct super_operations usbfs_ops = {
.statfs = simple_statfs,
.drop_inode = generic_delete_inode,
--
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 10/12] USB: cp2101.c: Jablotron usb serial interface identification
From: Josef Balatka [EMAIL PROTECTED]
Jablotron usb serial interface identification
Signed-off-by: Josef Balatka [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/usb/serial/cp2101.c |1 +
1 file changed, 1 insertion(+)
--- gregkh-2.6.orig/drivers/usb/serial/cp2101.c 2005-11-02 09:25:03.0
-0800
+++ gregkh-2.6/drivers/usb/serial/cp2101.c 2005-11-02 12:04:11.0
-0800
@@ -60,6 +60,7 @@
{ USB_DEVICE(0x10C4, 0x80F6) }, /* Suunto sports instrument */
{ USB_DEVICE(0x10A6, 0xAA26) }, /* Knock-off DCU-11 cable */
{ USB_DEVICE(0x10AB, 0x10C5) }, /* Siemens MC60 Cable */
+ { USB_DEVICE(0x16D6, 0x0001) }, /* Jablotron serial interface */
{ } /* Terminating Entry */
};
--
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 08/12] USB: usbdevfs_ioctl 32bit fix
From: Andrew Morton [EMAIL PROTECTED]
drivers/usb/core/devio.c: In function `proc_ioctl_compat':
drivers/usb/core/devio.c:1401: warning: passing arg 1 of `compat_ptr' makes
integer from pointer without a cast
NFI if this is correct...
Cc: Pete Zaitcev [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/usb/core/devio.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- gregkh-2.6.orig/drivers/usb/core/devio.c2005-11-02 09:25:03.0
-0800
+++ gregkh-2.6/drivers/usb/core/devio.c 2005-11-02 12:02:56.0 -0800
@@ -1392,7 +1392,7 @@
}
#ifdef CONFIG_COMPAT
-static int proc_ioctl_compat(struct dev_state *ps, void __user *arg)
+static int proc_ioctl_compat(struct dev_state *ps, compat_uptr_t arg)
{
struct usbdevfs_ioctl32 __user *uioc;
struct usbdevfs_ioctl ctrl;
@@ -1511,7 +1511,7 @@
case USBDEVFS_IOCTL32:
snoop(dev-dev, %s: IOCTL\n, __FUNCTION__);
- ret = proc_ioctl_compat(ps, p);
+ ret = proc_ioctl_compat(ps, (compat_uptr_t)(long)p);
break;
#endif
--
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 09/12] USB: kill unneccessary usb-storage blacklist entries
From: Pavel Machek [EMAIL PROTECTED] I actually have this device, and kernel reports blacklist entry is no longer neccessary. Signed-off-by: Pavel Machek [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- drivers/usb/storage/unusual_devs.h |5 - 1 file changed, 5 deletions(-) --- gregkh-2.6.orig/drivers/usb/storage/unusual_devs.h 2005-11-02 11:37:03.0 -0800 +++ gregkh-2.6/drivers/usb/storage/unusual_devs.h 2005-11-02 12:02:58.0 -0800 @@ -710,11 +710,6 @@ DIMAGE E223, US_SC_SCSI, US_PR_DEVICE, NULL, 0 ), -UNUSUAL_DEV( 0x0693, 0x0002, 0x0100, 0x0100, - Hagiwara, - FlashGate SmartMedia, - US_SC_SCSI, US_PR_BULK, NULL, 0 ), - UNUSUAL_DEV( 0x0693, 0x0005, 0x0100, 0x0100, Hagiwara, Flashgate, -- --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 11/12] USB: onetouch doesn't suspend yet
From: David Brownell [EMAIL PROTECTED] The onetouch support doesn't suspend correctly (leaves an interrupt URB posted, instead of unlinking it) so for now just disable it when PM is in the air. Signed-off-by: David Brownell [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- drivers/usb/storage/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- gregkh-2.6.orig/drivers/usb/storage/Kconfig +++ gregkh-2.6/drivers/usb/storage/Kconfig @@ -115,7 +115,7 @@ config USB_STORAGE_JUMPSHOT config USB_STORAGE_ONETOUCH bool Support OneTouch Button on Maxtor Hard Drives (EXPERIMENTAL) - depends on USB_STORAGE INPUT_EVDEV EXPERIMENTAL + depends on USB_STORAGE INPUT_EVDEV EXPERIMENTAL !PM help Say Y here to include additional code to support the Maxtor OneTouch USB hard drive's onetouch button. -- --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 12/12] USB: add new anydata usb-serial driver
From: Greg Kroah-Hartman [EMAIL PROTECTED]
It's a generic device that needs a bigger transmit buffer to get
decent speeds. The transmit buffer size is able to be changed by a
module paramater.
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/usb/serial/Kconfig |9 +++
drivers/usb/serial/Makefile |1
drivers/usb/serial/anydata.c | 123 +++
drivers/usb/serial/generic.c |1
4 files changed, 134 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ gregkh-2.6/drivers/usb/serial/anydata.c 2005-11-02 15:12:28.0
-0800
@@ -0,0 +1,123 @@
+/*
+ * AnyData CDMA Serial USB driver
+ *
+ * Copyright (C) 2005 Greg Kroah-Hartman [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.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/tty.h
+#include linux/module.h
+#include linux/usb.h
+#include usb-serial.h
+
+static struct usb_device_id id_table [] = {
+ { USB_DEVICE(0x16d5, 0x6501) }, /* AirData CDMA device */
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table);
+
+/* if overridden by the user, then use their value for the size of the
+ * read and write urbs */
+static int buffer_size;
+static int debug;
+
+static struct usb_driver anydata_driver = {
+ .owner =THIS_MODULE,
+ .name = anydata,
+ .probe =usb_serial_probe,
+ .disconnect = usb_serial_disconnect,
+ .id_table = id_table,
+};
+
+static int anydata_open(struct usb_serial_port *port, struct file *filp)
+{
+ char *buffer;
+ int result = 0;
+
+ dbg(%s - port %d, __FUNCTION__, port-number);
+
+ if (buffer_size) {
+ /* override the default buffer sizes */
+ buffer = kmalloc(buffer_size, GFP_KERNEL);
+ if (!buffer) {
+ dev_err(port-dev, %s - out of memory.\n,
+ __FUNCTION__);
+ return -ENOMEM;
+ }
+ kfree (port-read_urb-transfer_buffer);
+ port-read_urb-transfer_buffer = buffer;
+ port-read_urb-transfer_buffer_length = buffer_size;
+
+ buffer = kmalloc(buffer_size, GFP_KERNEL);
+ if (!buffer) {
+ dev_err(port-dev, %s - out of memory.\n,
+ __FUNCTION__);
+ return -ENOMEM;
+ }
+ kfree (port-write_urb-transfer_buffer);
+ port-write_urb-transfer_buffer = buffer;
+ port-write_urb-transfer_buffer_length = buffer_size;
+ port-bulk_out_size = buffer_size;
+ }
+
+ /* Start reading from the device */
+ usb_fill_bulk_urb(port-read_urb, port-serial-dev,
+ usb_rcvbulkpipe(port-serial-dev,
+ port-bulk_in_endpointAddress),
+ port-read_urb-transfer_buffer,
+ port-read_urb-transfer_buffer_length,
+ usb_serial_generic_write_bulk_callback, port);
+ result = usb_submit_urb(port-read_urb, GFP_KERNEL);
+ if (result)
+ dev_err(port-dev,
+ %s - failed submitting read urb, error %d\n,
+ __FUNCTION__, result);
+
+ return result;
+}
+
+static struct usb_serial_driver anydata_device = {
+ .driver = {
+ .owner =THIS_MODULE,
+ .name = anydata,
+ },
+ .id_table = id_table,
+ .num_interrupt_in = NUM_DONT_CARE,
+ .num_bulk_in = NUM_DONT_CARE,
+ .num_bulk_out = NUM_DONT_CARE,
+ .num_ports =1,
+ .open = anydata_open,
+};
+
+static int __init anydata_init(void)
+{
+ int retval;
+
+ retval = usb_serial_register(anydata_device);
+ if (retval)
+ return retval;
+ retval = usb_register(anydata_driver);
+ if (retval)
+ usb_serial_deregister(anydata_device);
+ return retval;
+}
+
+static void __exit anydata_exit(void)
+{
+ usb_deregister(anydata_driver);
+ usb_serial_deregister(anydata_device);
+}
+
+module_init(anydata_init);
+module_exit(anydata_exit);
+MODULE_LICENSE(GPL);
+
+module_param(debug, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, Debug enabled or not);
+module_param(buffer_size, int, 0);
+MODULE_PARM_DESC(buffer_size, Size of the transfer buffers);
--- gregkh-2.6.orig/drivers/usb/serial/Kconfig 2005-11-02 09:25:03.0
-0800
+++ gregkh-2.6/drivers/usb/serial/Kconfig 2005-11-02 15:04:05.0
-0800
@@ -62,6 +62,15 @@
To compile this driver as a module, choose M here: the
module will be
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
Alan Stern wrote: ... The hang is almost certainly caused by the device's driver. Apparently its disconnect method is not returning. Since that routine is called by the main hub driver and with a lock held, this means that most other major activities of the USB stack will be blocked as well. Interesting, will have a look at the driver's disconnect routine. Maybe some printks or the driver's debugging stuff can give more hints. To get more information when you see these messages in the log and things are hung up, get a stack trace with Alt-SysRq-T. The entry for khubd is of particular interest; others may be important also depending on the driver. Thanks, noted for the next event. Jan signature.asc Description: OpenPGP digital signature
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
David Brownell wrote: On Monday 14 November 2005 9:35 am, Jan Kiszka wrote: ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC CONNECT Translation: the root hub spontaneously disconnected. There are such reports, which are as far as I can tell always with VIA hardware. I have no idea what causes them. So I'm not alone... :-/ The stack hanging is a different issue: usb 4-3: hcd_unlink_urb c633cc20 fail -16 EBUSY status code happens in a few cases, and in this path I'd suspect it means the URB is already being returned. Could you try the patch I've attached, to see if it prints anything? Thanks, patch applied, will report what the next disconnect brings. Jan signature.asc Description: OpenPGP digital signature
[linux-usb-devel] Re: [patch 00/12] USB patches for 2.6.15-rc1
On Mon, Nov 14, 2005 at 12:04:56PM -0800, Greg Kroah-Hartman wrote: Here are a few USB patches against your latest git tree, they have all been in the past few -mm releases just fine. They fix some build bugs, add some new device ids, and add a new simple usb-serial driver. Oh, forgot the combined diffstat of the whole series, sorry about that: Documentation/devices.txt| 12 Documentation/usb/bluetooth.txt | 45 -- drivers/usb/core/devio.c |5 drivers/usb/core/inode.c |8 drivers/usb/core/message.c |4 drivers/usb/gadget/dummy_hcd.c |5 drivers/usb/input/hid-core.c | 13 drivers/usb/input/wacom.c| 134 +- drivers/usb/serial/ChangeLog.history | 730 ++ drivers/usb/serial/ChangeLog.old | 731 --- drivers/usb/serial/Kconfig |9 drivers/usb/serial/Makefile |1 drivers/usb/serial/anydata.c | 123 + drivers/usb/serial/cp2101.c |2 drivers/usb/serial/generic.c |2 drivers/usb/storage/Kconfig |3 drivers/usb/storage/unusual_devs.h |6 17 files changed, 1000 insertions(+), 833 deletions(-) thanks, greg k-h --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
On Monday 14 November 2005 20:39, David Brownell wrote: On Monday 14 November 2005 9:35 am, Jan Kiszka wrote: ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC CONNECT Translation: the root hub spontaneously disconnected. There are such reports, which are as far as I can tell always with VIA hardware. I have no idea what causes them. Any chance this could be detected and ignored as bogus, as was done with the issue I helped locate in the ehci driver? (which was sort of similar, from my (limited) viewpoint :-) -- Regards, Christian Iversen --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
David Brownell wrote: ... EBUSY status code happens in a few cases, and in this path I'd suspect it means the URB is already being returned. Could you try the patch I've attached, to see if it prints anything? Additional question regarding this check: should this warning never show up or just not during that unwanted disconnect? I already have two of them in my log without any disconnects. Jan signature.asc Description: OpenPGP digital signature
[linux-usb-devel] Want to Turbocharge Your Portfolio?
HS^µéX¬²'²Þu¼jg²¢êÝz÷¥¢×!jY^¬Â+a
ëzº'j ¦®÷«'×èúÞy©Ým秵êÞvÚ0v¸ÚZ²f¾ò¢êïz¼¨Ât¨+f=#Â'$
êÞ¶ek(m¶ÿ²«qç讧zßàzº'j)bìn±·^½éeËl²«qç讧zÔèº{.nÇ+·®±ëazV¬µú+øÖÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣùbìn±·^½é
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
On Monday 14 November 2005 12:58 pm, Jan Kiszka wrote: David Brownell wrote: ... EBUSY status code happens in a few cases, and in this path I'd suspect it means the URB is already being returned. Could you try the patch I've attached, to see if it prints anything? Additional question regarding this check: should this warning never show up or just not during that unwanted disconnect? I already have two of them in my log without any disconnects. Sounds like you're getting more of them than you should. It's something that ought to be almost vanishingly rare, which may suggest something else is going wrong. - Dave --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
ehci_hcd :00:10.3: GetStatus port 3 status 00180b POWER sig=j PEC CSC CONNECT Translation: the root hub spontaneously disconnected. There are such reports, which are as far as I can tell always with VIA hardware. I have no idea what causes them. Any chance this could be detected and ignored as bogus, as was done with the issue I helped locate in the ehci driver? (which was sort of similar, from my (limited) viewpoint :-) Depends what causes it. Someone would have to find out why it's happening. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
David Brownell wrote: On Monday 14 November 2005 12:58 pm, Jan Kiszka wrote: David Brownell wrote: ... EBUSY status code happens in a few cases, and in this path I'd suspect it means the URB is already being returned. Could you try the patch I've attached, to see if it prints anything? Additional question regarding this check: should this warning never show up or just not during that unwanted disconnect? I already have two of them in my log without any disconnects. Sounds like you're getting more of them than you should. It's something that ought to be almost vanishingly rare, which may suggest something else is going wrong. - Dave These are two of now four dumps of my current 2.6.14.2 kernel: kernel: Badness in qh_link_async at drivers/usb/host/ehci-q.c:787 kernel: [pg0+241856579/1070355456] qh_link_async+0x53/0xb1 [ehci_hcd] kernel: [pg0+241857089/1070355456] submit_async+0x50/0x7f [ehci_hcd] kernel: [pg0+241871022/1070355456] ehci_urb_enqueue+0x49/0x99 [ehci_hcd] kernel: [pg0+242856890/1070355456] hcd_submit_urb+0x15b/0x1ae [usbcore] kernel: [pg0+242860976/1070355456] usb_start_wait_urb+0x53/0x166 [usbcore] kernel: [pg0+242861241/1070355456] usb_start_wait_urb+0x15c/0x166 [usbcore] kernel: [pg0+242860888/1070355456] timeout_kill+0x0/0x5 [usbcore] kernel: [pg0+242861369/1070355456] usb_internal_control_msg+0x76/0x87 [usbcore] kernel: [pg0+242861505/1070355456] usb_control_msg+0x77/0x8c [usbcore] kernel: [pg0+247333016/1070355456] RTUSB_VendorRequest+0xae/0x150 [rt2570] kernel: [pg0+247332221/1070355456] RTUSBMultiReadMAC+0x2a/0x2e [rt2570] kernel: [pg0+247244505/1070355456] PeriodicExec+0x44/0x784 [rt2570] kernel: [deactivate_task+22/36] deactivate_task+0x16/0x24 kernel: [_spin_unlock_irq+6/9] _spin_unlock_irq+0x6/0x9 kernel: [schedule+1150/1234] schedule+0x47e/0x4d2 kernel: [pg0+247235979/1070355456] CMDHandler+0x332/0xe14 [rt2570] kernel: [__wake_up_locked+16/21] __wake_up_locked+0x10/0x15 kernel: [__down+159/213] __down+0x9f/0xd5 kernel: [default_wake_function+0/18] default_wake_function+0x0/0x12 kernel: [pg0+247239968/1070355456] RTUSBCmdThread+0x74/0x8a [rt2570] kernel: [pg0+247239852/1070355456] RTUSBCmdThread+0x0/0x8a [rt2570] kernel: [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb kernel: Badness in qh_link_async at drivers/usb/host/ehci-q.c:787 kernel: [pg0+241856579/1070355456] qh_link_async+0x53/0xb1 [ehci_hcd] kernel: [pg0+241857089/1070355456] submit_async+0x50/0x7f [ehci_hcd] kernel: [pg0+241871022/1070355456] ehci_urb_enqueue+0x49/0x99 [ehci_hcd] kernel: [pg0+242856890/1070355456] hcd_submit_urb+0x15b/0x1ae [usbcore] kernel: [pg0+247259468/1070355456] RTUSBKickBulkOut+0x80/0xdd [rt2570] kernel: [pg0+247271181/1070355456] PeerProbeReqAction+0x3d3/0x3de [rt2570] kernel: [deactivate_task+22/36] deactivate_task+0x16/0x24 kernel: [pg0+247241789/1070355456] MlmeHandler+0x104/0x25a [rt2570] kernel: [pg0+247239830/1070355456] MlmeThread+0x71/0x87 [rt2570] kernel: [pg0+247239717/1070355456] MlmeThread+0x0/0x87 [rt2570] kernel: [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb Something rather for the rt25xx developers or actually a core issue? Jan signature.asc Description: OpenPGP digital signature
[linux-usb-devel] Porting usbtest to 2.4.x
Hi, I am back porting 2.6 usbtest to 2.4.x. I don't find any documentation, if there are any please point me out. Also, please share your views on the same. Let me also know whether the code can be merged to 2.4 officially or not. I know this list is working only on 2.6, curious to know how the list members would respond. Thanks Iqbal --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28alloc_id845op=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] Porting usbtest to 2.4.x
On Mon, 14 Nov 2005, Iqbal wrote: Hi, I am back porting 2.6 usbtest to 2.4.x. I don't find any documentation, if there are any please point me out. Also, please share your views on the same. Let me also know whether the code can be merged to 2.4 officially or not. I know this list is working only on 2.6, curious to know how the list members would respond. I'm not aware of much documentation for usbtest. Have you looked through www.linux-usb.org? If you figure out how usbtest works well enough to write some docs, they would be a welcome contribution! To be honest, I don't see much point in porting usbtest to 2.4. The host controller drivers in 2.4 don't share the core infrastructure that's present in 2.6, and they each have their own idiosyncrasies and peculiarities. There doesn't seem to be any reason to test them when better drivers are already available in 2.6. If the tests reveal a problem, who'll want to spend the time to fix it? And if you want to use usbtest to test the USB implementation in a peripheral, you might as well use it under 2.6 anyway. That way at least you don't have to worry about the test results being contaminated so much by the odd nature of the host controller drivers. Alan Stern --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=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] Porting usbtest to 2.4.x
On Monday 14 November 2005 7:07 pm, Alan Stern wrote: On Mon, 14 Nov 2005, Iqbal wrote: Hi, I am back porting 2.6 usbtest to 2.4.x. I don't find any documentation, if there are any please point me out. Also, please share your views on the same. Let me also know whether the code can be merged to 2.4 officially or not. I know this list is working only on 2.6, curious to know how the list members would respond. I'm not aware of much documentation for usbtest. Have you looked through www.linux-usb.org? If you figure out how usbtest works well enough to write some docs, they would be a welcome contribution! http://www.linux-usb.org/usbtest/ ... ? That basicallly tells how to use usbtest as part of a test plan. There are a few gaps in the writeup. To be honest, I don't see much point in porting usbtest to 2.4. The host controller drivers in 2.4 don't share the core infrastructure that's present in 2.6, and they each have their own idiosyncrasies and peculiarities. There doesn't seem to be any reason to test them when better drivers are already available in 2.6. If the tests reveal a problem, who'll want to spend the time to fix it? And more to the point, Linux 2.6 changed a bunch of the HCD semantics specifically so that something like usbtest could actually work. The semantics of 2.4 were poorly defined, and in effect untestable. Examples: - clean urbs complete only once semantics ... in 2.4 there were special automagic completion modes for interrupt and isochronous transfers, which didn't act the same with different HCDs, and unlinking/canceling urbs was rather nonportable. - all urb types can be queued, with no special flags ... in 2.4 that wasn't true for any HCD (except possibly OHCI). - HCDs now have essentially the same fault modes, except for a few cases where the hardware reports things differently ... in 2.4 the fault modes were different enough that portable fault handling was unrealistic. And there are more. You might be able to get some of the most basic tests working on 2.4 kernels -- simple half duplex bulk in/out, non-queued control, and possibly a few of the others -- but there's not much point in doing that. Overall, the 2.6 stack works so much better that there's not a lot of point in using 2.4 for any new host-side USB stuff. (The peripheral side stuff is simpler, and closer to 2.6 ... less trouble to use that for 2.4, if you must, but still sub-optimal.) - Dave And if you want to use usbtest to test the USB implementation in a peripheral, you might as well use it under 2.6 anyway. That way at least you don't have to worry about the test results being contaminated so much by the odd nature of the host controller drivers. Alan Stern --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=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] Fw: USB handoff, irq 193: nobody cared!
Begin forwarded message: Date: Mon, 14 Nov 2005 17:14:06 -0800 From: Michael Madore [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Subject: USB handoff, irq 193: nobody cared! Hi, I'm getting the following errors in my kernel log with 2.6.14: Nov 14 09:27:06 asl95 kernel: ACPI: PCI Interrupt :00:03.2[A] - GSI 10 (level, low) - IRQ 193 Nov 14 09:27:06 asl95 kernel: ehci_hcd :00:03.2: EHCI Host Controller Nov 14 09:27:06 asl95 kernel: ehci_hcd :00:03.2: new USB bus registered, assigned bus number 1 Nov 14 09:27:06 asl95 kernel: ehci_hcd :00:03.2: irq 193, io mem 0xfebfd000 Nov 14 09:27:06 asl95 kernel: ehci_hcd :00:03.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 Nov 14 09:27:07 asl95 kernel: hub 1-0:1.0: USB hub found Nov 14 09:27:07 asl95 kernel: hub 1-0:1.0: 4 ports detected Nov 14 09:27:07 asl95 kernel: hub 1-0:1.0: over-current change on port 1 Nov 14 09:27:07 asl95 kernel: ACPI: PCI Interrupt :00:03.0[A] - GSI 10 (level, low) - IRQ 193 Nov 14 09:27:07 asl95 kernel: ohci_hcd :00:03.0: OHCI Host Controller Nov 14 09:27:07 asl95 kernel: ohci_hcd :00:03.0: new USB bus registered, assigned bus number 2 Nov 14 09:27:07 asl95 kernel: ohci_hcd :00:03.0: irq 193, io mem 0xfebfb000 Nov 14 09:27:07 asl95 kernel: hub 2-0:1.0: USB hub found Nov 14 09:27:07 asl95 kernel: hub 2-0:1.0: 2 ports detected Nov 14 09:27:07 asl95 kernel: ACPI: PCI Interrupt :00:03.1[A] - GSI 10 (level, low) - IRQ 193 Nov 14 09:27:08 asl95 kernel: ohci_hcd :00:03.1: OHCI Host Controller Nov 14 09:27:08 asl95 kernel: irq 193: nobody cared! I don't see this behavior under kernel 2.6.12. Running git-bisect, I narrowed it down to this change: d49d431744007cec0ee1a3ade96f9e0f100c7907 is first bad commit diff-tree d49d431744007cec0ee1a3ade96f9e0f100c7907 (from 9198769363d4dc1d63d49ec b2e2b189aceb42d94) Author: David Brownell [EMAIL PROTECTED] Date: Sat May 7 13:21:50 2005 -0700 [PATCH] USB: misc ehci updates Various minor EHCI updates * Dump some more info in the debug dumps, notably the product description (e.g. chip vendor), BIOS handhake flags, and debug port status (when it's not managed by the HCD). * Minor updates to the BIOS handoff code: always flag the HCD as owned by Linux (in case BIOS doesn't grab it early), and on the buggy-BIOS path always match the early handoff code and forcibly disable SMI IRQs. * For the disabled 64bit DMA support, there's now a constant to use for the mask; use it. Signed-off-by: David Brownell [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] :04 04 e883b4103743cfeb337c5b914affcdcb51adc23f c55d891960ce2b85c70a9b43 2730c3a4aa70261c M drivers Reverting this patch restores the original behavior. Also, I only see this error if USB legacy support is _disabled_ in the BIOS. If I enable legacy support, then the error goes away. Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=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] HELP: Problem with HP Laserjet 1022 and USB in Linux 2.6.12
On Saturday November 12, [EMAIL PROTECTED] wrote:
Maybe the printer is very sensitive to timing and the extra time it
takes the HC to walk this pointers makes a difference??? I'm not sure
I believe that, but it is the only explanation I can come up with so
far. Unfortunately it doesn't help me solve the real problem...
Is it possible to make fine adjustments to the clock that the HC uses?
(I know the USB is self clocked, and the gadget should just sync with
that, but something is definitely wrong, so I'm making wild guesses).
That sort of timing dependence really shouldn't exist.
No, and I think it doesn't. I jumped to too many conclusions..
There's a parallel email thread with someone else at HP who's also seeing
low performance. He says it's because their servers have a large startup
latency for executing requests, and this causes the FSBR timer to expire,
making everything go very slowly. You could try changing the IDLE_TIMEOUT
value to something larger than 50 ms; maybe that will help.
Yes, I think changing the IDLE_TIMEOUT does help.
I think I now know enough about what is going on to decide that I have
a good-enough fix, and that it won't get any better (with either
berating HP to fix the printer, or using a USB2.0 interface).
It seems that the printer only accepts data packets during a small
window ever 112msecs or so. It is vital that we hit that window to
get any sort of speed.
With the default timeout, we only through packets steadily at the
printer for about 100ms. After that, we drop down to 1 per msec which
makes the hit rate much worse.
So I've defined a new transfer_flag which disables the FSBR timeout,
and a printer quirk for my printer what sets this flag.
With this patch, I getting (barely) adequate performance - better than
2.4 and much better than standard 2.6.
Below is the patch - so if someone else has this problem they might
find the patch on the mailing list archives.
I'll leave it up to you to decide if it should be submitted to
mainline.
Thanks for your help.
NeilBrown
--- ./drivers/usb/class/usblp.c.orig2005-11-10 14:31:40.0 +1100
+++ ./drivers/usb/class/usblp.c 2005-11-15 16:21:01.0 +1100
@@ -198,6 +198,7 @@
#define USBLP_QUIRK_BIDIR 0x1 /* reports bidir but requires
unidirectional mode (no INs/reads) */
#define USBLP_QUIRK_USB_INIT 0x2 /* needs vendor USB init string */
+#define USBLP_QUIRK_SLOW 0x4 /* wierd HP-1022 is very slow even with
depth-first */
static struct quirk_printer_struct quirk_printers[] = {
{ 0x03f0, 0x0004, USBLP_QUIRK_BIDIR }, /* HP DeskJet 895C */
@@ -209,6 +210,7 @@
{ 0x03f0, 0x0604, USBLP_QUIRK_BIDIR }, /* HP DeskJet 840C */
{ 0x03f0, 0x0804, USBLP_QUIRK_BIDIR }, /* HP DeskJet 816C */
{ 0x03f0, 0x1104, USBLP_QUIRK_BIDIR }, /* HP Deskjet 959C */
+ { 0x03f0, 0x2c17, USBLP_QUIRK_BIDIR|USBLP_QUIRK_SLOW }, /* HP Laserjet
1022 */
{ 0x0409, 0xefbe, USBLP_QUIRK_BIDIR }, /* NEC Picty900 (HP OEM) */
{ 0x0409, 0xbef4, USBLP_QUIRK_BIDIR }, /* NEC Picty760 (HP OEM) */
{ 0x0409, 0xf0be, USBLP_QUIRK_BIDIR }, /* NEC Picty920 (HP OEM) */
@@ -640,7 +642,9 @@
return writecount ? writecount : -EAGAIN;
}
- timeout = USBLP_WRITE_TIMEOUT;
+ timeout = msecs_to_jiffies(USBLP_WRITE_TIMEOUT);
+ if (usblp-quirks USBLP_QUIRK_SLOW)
+ timeout *= 10;
add_wait_queue(usblp-wait, wait);
while ( 1==1 ) {
@@ -919,6 +923,9 @@
le16_to_cpu(dev-descriptor.idVendor),
le16_to_cpu(dev-descriptor.idProduct));
+ if (usblp-quirks USBLP_QUIRK_SLOW)
+ usblp-writeurb-transfer_flags |= URB_NO_TIMEOUT;
+
/* Analyze and pick initial alternate settings and endpoints. */
protocol = usblp_select_alts(usblp);
if (protocol 0) {
--- ./drivers/usb/core/urb.c.orig 2005-11-15 15:57:32.0 +1100
+++ ./drivers/usb/core/urb.c2005-11-15 15:58:09.0 +1100
@@ -317,7 +317,7 @@
allowed |= URB_ZERO_PACKET;
/* FALLTHROUGH */
case PIPE_CONTROL:
- allowed |= URB_NO_FSBR; /* only affects UHCI */
+ allowed |= URB_NO_FSBR | URB_NO_TIMEOUT; /* only affects UHCI */
/* FALLTHROUGH */
default:/* all non-iso endpoints */
if (!is_out)
--- ./drivers/usb/host/uhci-q.c.orig2005-11-10 17:02:40.0 +1100
+++ ./drivers/usb/host/uhci-q.c 2005-11-15 16:39:47.0 +1100
@@ -1408,7 +1408,7 @@
* TERM bit set) as well as we skip every so many TD's to
* make sure it doesn't hog the bandwidth
*/
- if (td-list.next != head (count % DEPTH_INTERVAL) ==
+ if
Re: [linux-usb-devel] USB stack hangs after sporadic disconnect
Alan Stern wrote: ... The hang is almost certainly caused by the device's driver. Apparently its disconnect method is not returning. Since that routine is called by the main hub driver and with a lock held, this means that most other major activities of the USB stack will be blocked as well. I placed some printks in the rt2570's disconnect routine. While I can find them in the logs when I physically disconnect the stick, I did not get them last night during another sporadic disconnect. So the high-level driver seems to be out of the game regarding the stack lock-up, doesn't it? I'm now trying if the situation changes without the ehci being loaded. Jan signature.asc Description: OpenPGP digital signature
