Re: [linux-usb-devel] HTC as USB gprs/edge modem on linux
Am Dienstag 14 August 2007 schrieb bizu: $ lsusb -v Bus 001 Device 002: ID 0bb4:0303 High Tech Computer Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 3 RNDIS Neither cdc-acm nor rndis-host will bind to a device that says wireless rndis. One might try to hack the rndis-host driver. Can you test a patch? Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] spontaneous disconnect with usb-storage: implement autosuspend
Am Dienstag 14 August 2007 schrieb Paolo Ornati: Hi, with CONFIG_USB_SUSPEND=y, since commit: 8dfe4b14869fd185ca25ee88b02ada58a3005eaf usb-storage: implement autosuspend This patch (as930) implements autosuspend for usb-storage. It is adapted from a patch by Oliver Neukum. Autosuspend is allowed except during LUN scanning, resets, and command execution. my USB photo-camera gets automagically disconnected before I can do anything with it ;) hi, I need vendor:product. Please provide lsusb. Generally a bug report for a specific usb device without vendor:product is a bad idea. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iuu_phoenix - new release v0.4 - call for review/comments
Am Sonntag 12 August 2007 schrieb [EMAIL PROTECTED]:
In this release, the driver use the interrupt context.
So no more latency problem.
I still kfree the buffers provided by the usb-serial framework.
All comments/remarks are welcome
This driver seems very stable ( tested with 5 readers at the same time )
Alain
+static int iuu_alloc_buf(struct iuu_private *priv)
+{
+ priv-buf = kzalloc(256, GFP_KERNEL);
+ priv-dbgbuf = kzalloc(256, GFP_KERNEL);
+ priv-writebuf = kzalloc(256, GFP_KERNEL);
+ if (!priv-buf || !priv-dbgbuf || !priv-writebuf) {
+ dbg(%s problem allocation buffer, __FUNCTION__);
+ return -ENOMEM;
+ }
+ return 0;
+}
Memory leak. Only one allocation may have failed. You should
free all allocations in the error case. kfree() can take NULL.
+static int iuu_free_buf(struct iuu_private *priv)
+{
+ kfree(priv-buf);
+ kfree(priv-dbgbuf);
+ kfree(priv-writebuf);
+ return 0;
+}
What could fail? Make it void.
+ if (!(set TIOCM_RTS) priv-TIOSTATUS == TIOCM_RTS) {
+ dbg(%s TIOCMSET RESET called !!!, __FUNCTION__);
+ priv-reset = 1;
+ /* force waiting before return
+* needed by ctapi phoenix driver */
+ current-state = TASK_UNINTERRUPTIBLE;
+ schedule_timeout(1 + 1000 * HZ / 1000);
+ return 0;
+ }
+
The tty code can leave you on a waitqueue and wake you prematurely.
You must use a real waiting primitive.
+ kfree(port-bulk_out_buffer) ;
+ port-bulk_out_buffer = kmalloc(512, GFP_KERNEL);
+ port-bulk_out_size = 512 ;
+ kfree(port-bulk_in_buffer) ;
+ port-bulk_in_buffer = kmalloc(512, GFP_KERNEL);
+ port-bulk_in_size = 512 ;
This needs error handling.
And some other issues. Please fix this and resend.
Regards
Oliver
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iuu_phoenix - new release v0.4 - call for review/comments
Am Montag 13 August 2007 schrieb Alan Cox:
+static int iuu_alloc_buf(struct iuu_private *priv)
+{
+ priv-buf = kzalloc(256, GFP_KERNEL);
+ priv-dbgbuf = kzalloc(256, GFP_KERNEL);
+ priv-writebuf = kzalloc(256, GFP_KERNEL);
+ if (!priv-buf || !priv-dbgbuf || !priv-writebuf) {
+ dbg(%s problem allocation buffer, __FUNCTION__);
+ return -ENOMEM;
+ }
+ return 0;
+}
Given they have the same lifetime what is wrong with simply putting them
in struct iuu_private as arrays ?
Alignment issue for the architectures which don't have cache consistent DMA.
Regards
Oliver
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iuu_phoenix - new release v0.4 - call for review/comments
Am Montag 13 August 2007 schrieb Alan Cox:
On Mon, 13 Aug 2007 15:48:40 +0200
Oliver Neukum [EMAIL PROTECTED] wrote:
Am Montag 13 August 2007 schrieb Alan Cox:
+static int iuu_alloc_buf(struct iuu_private *priv)
+{
+ priv-buf = kzalloc(256, GFP_KERNEL);
+ priv-dbgbuf = kzalloc(256, GFP_KERNEL);
+ priv-writebuf = kzalloc(256, GFP_KERNEL);
+ if (!priv-buf || !priv-dbgbuf || !priv-writebuf) {
+ dbg(%s problem allocation buffer, __FUNCTION__);
+ return -ENOMEM;
+ }
+ return 0;
+}
Given they have the same lifetime what is wrong with simply putting them
in struct iuu_private as arrays ?
Alignment issue for the architectures which don't have cache consistent DMA.
Is using __cacheline_aligned not sufficient for that ?
I think so. You'd need to ask the dma layer guys for a definitive answer.
However, is it simpler?
Regards
Oliver
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.23-rc1: USB hard disk broken
Am Sonntag 05 August 2007 schrieb Tino Keitel: I tried again -rc1 without USB_DEBUG, and was able to reproduce the bug 2 times. At the second time, the kernel log shows this: Hi Tino, could you please test an _earlier_ kernel. We need to know which kernel introduced this bug. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Disable autosuspend for scanners/printers
Am Donnerstag 09 August 2007 schrieb Alan Stern: Oliver and Pete: Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries for scanners with a single class-wide entry? Which class? It would have to blanket all vendor specific devices. This is a rather broad swipe. What about printers? Just remove the autosuspend support from the driver if you really want to do this. Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need NO_AUTOSUSPEND? Having no way to test, I am conservative. Besides, is RESET_RESUME the right thing to do for a device driven by usbfs? It would turn close() into an operation that can cause a reset as a side effect. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Disable autosuspend for scanners/printers
Am Sonntag 12 August 2007 schrieb Alan Stern: On Sun, 12 Aug 2007, Oliver Neukum wrote: Am Donnerstag 09 August 2007 schrieb Alan Stern: Oliver and Pete: Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries for scanners with a single class-wide entry? Which class? It would have to blanket all vendor specific devices. This is a rather broad swipe. I was hoping there would be a specific device class for scanners. Oh well. It is a flaw in the USB spec. I'm beginning to agree with Matthew Garrett that autosuspend should be disabled by default except for known-good devices and device classes... We could simply revert to enabling autosuspend only for those devices whose driver requests it. Most problems are with devices accessed through usbfs. What about printers? Just remove the autosuspend support from the driver if you really want to do this. Is that good enough? If a printer is plugged in when the system boots, the delay between enumerating the device and loading the driver can be long enough for the device to get autosuspended. How many devices truely crash? Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need NO_AUTOSUSPEND? Having no way to test, I am conservative. Besides, is RESET_RESUME the right thing to do for a device driven by usbfs? It would turn close() into an operation that can cause a reset as a side effect. There's nothing wrong with that. The kernel makes no guarantees about what happens to a device driven by usbfs while its file is closed. The next program to open the file can't depend on finding the device in any particular state; this has always been true. In theory you are right. In theory there's no difference to practice. Before autsuspend the kernel left devices alone unless user space requested action. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB subsystem (part of it) hangs
Am Samstag 11 August 2007 schrieb Paulo da Silva: I would like to ask a question. Sorry if this is a silly question but I don't know kernel internals and what kind of info 't' produces. It produces a trace of all tasks in the system. Is it safe to post that output here, considering this is my production system? It's very difficult to get the situation on a special test system since it is relatively rare. It may take 5 mins or 2 days to occur. You will reveal to a potential attacker which tasks are running on your system. You could trim the output by removing all tasks' output which are not related to USB. The output is long but clear. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for asix driver
Am Freitag 03 August 2007 schrieb David Brownell: On Wednesday 01 August 2007, Oliver Neukum wrote: Am Dienstag 31 Juli 2007 schrieb Alan Stern: You assign dev-intf in both the usbnet framework driver and the subdriver. Could the subdriver's assignment be removed? Here we go again. Regards Oliver Signed-off-by: Oliver Neukum [EMAIL PROTECTED] You know that drivers/net/usb patches go to the netdev list, right? They merge through the network queue, not the USB queue. Even patches that have no relation to networking as such? This looks plausible to me, except /* multi-line comments * in the code * should not end like this: */ /* do it like this, with * nice clean line endings: */ It shall be done. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
Am Freitag 03 August 2007 schrieb Matthew Garrett: Also, we have udev rules for SANE that disables their autosuspend settings, which handles the majority of the devices we have seen with problems. Several printers seem to have the issue as well, and the blacklist seems to contain some odd miscellaneous devices like the Blackberry. The main Then make autosuspend support for the printer driver a config option. This is not a reason to change the core usb code. The core code needs to be involved only for device that are driven through usbfs. The major types are: - scanners - PTP devices - OBEX Scanners are covered by SANE's latest CVS PTP are a class and could be covered by a single udev rule Obex is comm, so the patch wouldn't help. concern I have is that kernel developers just don't tend to be the sort of people that use webcams, printers or scanners, so we're relying on normal users to go to the effort of reporting that their device has stopped working. Kernel developers are a diverser lot than you think ;-) We don't enable autosuspend in drivers we can't test, except where the lack of a kernel driver forces us to use a broad swipe. Printers were tested, too, and most printers seem to work. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci problem triggerable by storage
Am Freitag 03 August 2007 schrieb Greg KH: On Mon, Jul 30, 2007 at 11:11:54AM -0700, David Brownell wrote: On Monday 30 July 2007, Oliver Neukum wrote: But -- never actually having had both a highspeed USB sniffer *AND* hardware exhibiting this problem in the same place -- I've not been able to test that theory. The hub in question is light and small. Give me your address and I'll put it in the mail. You'd need to send a high speed sniffer with it. ;) I was thinking that Oliver Neukum [EMAIL PROTECTED] ought to have ready access to such a sniffer. SuSE certainly should have sprung for one by now. Hahahahaha, oh, that's a good one... Heck, when I worked at a company that made huge systems that relied on USB to work properly, such sniffers were not available. So for a company that only creates software to be able to buy such a thing, well, that's a very nice dream... Well, I've thought a bit about this. I know a hub is to blame. Even if I did learn what causes this specific error, it wouldn't help in the other cases. IMHO improving error handling is better than avoiding this fault. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] About current state of supporting USB selective suspend feature
Am Freitag 03 August 2007 schrieb gutian abei: Dear All: I am trying to develop a USB device driver in Linux platform. Our device has the ability of re-enumeration. That is when our device plug into host PC it reports a vid/pid, for example 0x/0x, after 10 seconds it changes the state of D+ and D- to let PC enumerate it again, and it reports a new vid/pid, for example 0x/0x. Then our device uses 0x/0x to play with host PC. But in my Fedora 7 system(I install it today, not update yet!), it doesn't enumerate the second vid/pid. It just enumerate the first vid/pid(0x/0x). I use usbview tool to test my device. Does anyone have experience to resolve it? Thank you! With Best Regard! Does it keep working? If not, enable CONFIG_USB_DEBUG and look at the log file. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: Only enable a utosuspend by default on certain device classes
Am Freitag 03 August 2007 schrieb Dave Jones: On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote: Kernel developers are a diverser lot than you think ;-) We don't enable autosuspend in drivers we can't test, except where the lack of a kernel driver forces us to use a broad swipe. Printers were tested, too, and most printers seem to work. My experience suggests the opposite. Of the several I've tried so far, none have worked with usb suspend. vendor:product please. In addition, I'll make a config option for usblp using autosuspend. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
Am Freitag 03 August 2007 schrieb Matthew Garrett: On Thu, Aug 02, 2007 at 11:01:08PM -0700, David Brownell wrote: Seems to me it ought to be practical to organize a database that can be consulted by an outcall from udev, disabling autosuspend on devices which are known to be broken. The modules.usbmap syntax is an obvious place to start (painful though it is), and I'm sure there are folk who would prefer web-accessible/updatable databases. It's certainly possible to do that, but it's also possible to have a userspace solution that whitelists devices. The question is whether the default kernel behaviour should be Save power, but potentially break some of my devices or Don't break my devices, but use some more powre. If both options have drawbacks, IMHO we follow the standard, which says that devices must support suspension. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
Am Freitag 03 August 2007 schrieb Matthew Garrett: Which is why I didn't suggest doing that, of course. The only one making that kind of straw man argument seems to be you. But however you phrase it, that's effectively what it is. Does your device work? just makes users wonder why the damn computer doesn't know already. This option may prevent your device from working. Click here to switch it off results in them wondering why it was switched on in the first place. Many of our users aren't technical - they don't care about saving 200mW, they just care about their printer working when they plug it in. Devices rarely simply crash. Although Windows doesn't do runtime power management, it certainly will suspend all devices when the system goes into suspension. Buggy devices typically disconnect and reconnect when resumed. This is testable for in software without user intervention. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] How to write a user-space application for usb_skeleton?
Am Donnerstag 02 August 2007 schrieb Thaens Tim: I've compiled the usb_skeleton.c module and loaded this module. I've managed to open a USB-device, but that's it. How can I write a application that uses this module? Can I only use the file-operations like (owner, read, write, open and release)? Yes. Is there a way to set the baudrate, get the vendor/device ID, search for USB devices, ... No, you need a specialised driver for that. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Can't unload uhci_hcd module with 2.6.22 -- also oops
Am Donnerstag 02 August 2007 schrieb Alan Stern: On Wed, 1 Aug 2007, Alan Stern wrote: Okay, good work. Thanks to your careful experiments, plus the hints from Oliver and Tejun, I figured out the problem. In short, the attribute files were registered on the control interface but the driver tried to delete them from the data interface. I'll post a patch tomorrow morning. And here it is. You can remove the earlier diagnostic patches; this one by itself should fix everything. Alan Stern Alan, thanks for finding this. I saw sysfs in the trace and switched off mentally. Sorry Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] cdc-acm: fix sysfs attribute registration bug
Am Donnerstag 02 August 2007 schrieb Alan Stern: This patch (as950) fixes a bug in the cdc-acm driver. It doesn't keep track of which interface (control or data) the sysfs attributes get registered for, and as a result, during disconnect it will sometimes attempt to remove the attributes from the wrong interface. The left-over attributes can cause a crash later on, particularly if the driver module has been unloaded. Signed-off-by: Alan Stern [EMAIL PROTECTED] Acked-by: Oliver Neukum [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for asix driver
Am Dienstag 31 Juli 2007 schrieb Alan Stern:
You assign dev-intf in both the usbnet framework driver and the
subdriver. Could the subdriver's assignment be removed?
Here we go again.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
---
--- a/drivers/net/usb/asix.c2007-07-30 14:18:38.0 +0200
+++ b/drivers/net/usb/asix.c2007-08-01 09:48:10.0 +0200
@@ -1474,6 +1474,7 @@ static struct usb_driver asix_driver = {
.suspend = usbnet_suspend,
.resume = usbnet_resume,
.disconnect = usbnet_disconnect,
+ .supports_autosuspend = 1,
};
static int __init asix_init(void)
--- a/drivers/net/usb/usbnet.h 2007-07-30 14:23:08.0 +0200
+++ b/drivers/net/usb/usbnet.h 2007-07-31 11:08:12.0 +0200
@@ -28,6 +28,7 @@
struct usbnet {
/* housekeeping */
struct usb_device *udev;
+ struct usb_interface*intf;
struct driver_info *driver_info;
const char *driver_name;
wait_queue_head_t *wait;
--- a/drivers/net/usb/usbnet.c 2007-07-30 14:27:40.0 +0200
+++ b/drivers/net/usb/usbnet.c 2007-07-31 11:07:51.0 +0200
@@ -590,6 +590,7 @@ static int usbnet_stop (struct net_devic
dev-flags = 0;
del_timer_sync (dev-delay);
tasklet_kill (dev-bh);
+ usb_autopm_put_interface(dev-intf);
return 0;
}
@@ -603,9 +604,19 @@ static int usbnet_stop (struct net_devic
static int usbnet_open (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- int retval = 0;
+ int retval;
struct driver_info *info = dev-driver_info;
+ if ((retval = usb_autopm_get_interface(dev-intf)) 0) {
+ if (netif_msg_ifup (dev))
+ devinfo (dev,
+ resumption fail (%d) usbnet usb-%s-%s, %s,
+ retval,
+ dev-udev-bus-bus_name, dev-udev-devpath,
+ info-description);
+ goto done_nopm;
+ }
+
// put into known safe state
if (info-reset (retval = info-reset (dev)) 0) {
if (netif_msg_ifup (dev))
@@ -659,7 +670,10 @@ static int usbnet_open (struct net_devic
// delay posting reads until we're fully open
tasklet_schedule (dev-bh);
+ return retval;
done:
+ usb_autopm_put_interface(dev-intf);
+done_nopm:
return retval;
}
@@ -1143,6 +1157,7 @@ usbnet_probe (struct usb_interface *udev
dev = netdev_priv(net);
dev-udev = xdev;
+ dev-intf = udev;
dev-driver_info = info;
dev-driver_name = name;
dev-msg_enable = netif_msg_init (msg_level, NETIF_MSG_DRV
@@ -1273,6 +1288,9 @@ int usbnet_suspend (struct usb_interface
netif_device_detach (dev-net);
(void) unlink_urbs (dev, dev-rxq);
(void) unlink_urbs (dev, dev-txq);
+ /* reattach so runtime management can use and
+* wake the device */
+ netif_device_attach (dev-net);
}
return 0;
}
@@ -1282,10 +1300,9 @@ int usbnet_resume (struct usb_interface
{
struct usbnet *dev = usb_get_intfdata(intf);
- if (!--dev-suspend_count) {
- netif_device_attach (dev-net);
+ if (!--dev-suspend_count)
tasklet_schedule (dev-bh);
- }
+
return 0;
}
EXPORT_SYMBOL_GPL(usbnet_resume);
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb-serial.c question - potential Memory fault
Am Dienstag 31 Juli 2007 schrieb Greg KH: So I agree with the proposition of Oliver to add a buffer_size in the usb_serial_driver structure. This is very useful to prepare a buffer able to make bulk transfer. I don't think it is necessary to add as it has not been a problem yet for any driver that I know of. This is intended for use of a new driver. Of course a driver can allocate its own buffer. But the purpose of the framework is to make subdrivers easier to write. So if a larger buffer is needed for some reason in the device's protocol, why not allocate it in the framework? I think you are just doing something wrong in your driver :) Currently yes. Either the API must be extended or the driver changed. As this is unlikely to remain the only driver with that problem, I propose extending the API. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] autosuspend for asix driver
Hi,
this implements autosuspend support for the asix subdriver of usbnet.
It works by autoresume when the device is opened and autosuspending when
it is closed. The logic is all put into the generic framework. All
the subdriver has to do is setting the flag.
To support this the suspend() method is changed so that the device is not
reported unready until resumption, as this prevents a new address being
assigned to the device, blocking autoresumption.
This method will have to be revisited if the freezer is removed, but the old
routine is also buggy without the freezer, as it switches the device off
while it may still be used.
It works for me, but I'd like general comments.
Regards
Oliver
---
--- a/drivers/net/usb/usbnet.h 2007-07-30 14:23:08.0 +0200
+++ b/drivers/net/usb/usbnet.h 2007-07-31 11:08:12.0 +0200
@@ -28,6 +28,7 @@
struct usbnet {
/* housekeeping */
struct usb_device *udev;
+ struct usb_interface*intf;
struct driver_info *driver_info;
const char *driver_name;
wait_queue_head_t *wait;
--- a/drivers/net/usb/usbnet.c 2007-07-30 14:27:40.0 +0200
+++ b/drivers/net/usb/usbnet.c 2007-07-31 11:07:51.0 +0200
@@ -590,6 +590,7 @@ static int usbnet_stop (struct net_devic
dev-flags = 0;
del_timer_sync (dev-delay);
tasklet_kill (dev-bh);
+ usb_autopm_put_interface(dev-intf);
return 0;
}
@@ -603,9 +604,19 @@ static int usbnet_stop (struct net_devic
static int usbnet_open (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- int retval = 0;
+ int retval;
struct driver_info *info = dev-driver_info;
+ if ((retval = usb_autopm_get_interface(dev-intf)) 0) {
+ if (netif_msg_ifup (dev))
+ devinfo (dev,
+ resumption fail (%d) usbnet usb-%s-%s, %s,
+ retval,
+ dev-udev-bus-bus_name, dev-udev-devpath,
+ info-description);
+ goto done_nopm;
+ }
+
// put into known safe state
if (info-reset (retval = info-reset (dev)) 0) {
if (netif_msg_ifup (dev))
@@ -659,7 +670,10 @@ static int usbnet_open (struct net_devic
// delay posting reads until we're fully open
tasklet_schedule (dev-bh);
+ return retval;
done:
+ usb_autopm_put_interface(dev-intf);
+done_nopm:
return retval;
}
@@ -1143,6 +1157,7 @@ usbnet_probe (struct usb_interface *udev
dev = netdev_priv(net);
dev-udev = xdev;
+ dev-intf = udev;
dev-driver_info = info;
dev-driver_name = name;
dev-msg_enable = netif_msg_init (msg_level, NETIF_MSG_DRV
@@ -1273,6 +1288,9 @@ int usbnet_suspend (struct usb_interface
netif_device_detach (dev-net);
(void) unlink_urbs (dev, dev-rxq);
(void) unlink_urbs (dev, dev-txq);
+ /* reattach so runtime management can use and
+* wake the device */
+ netif_device_attach (dev-net);
}
return 0;
}
@@ -1282,10 +1300,9 @@ int usbnet_resume (struct usb_interface
{
struct usbnet *dev = usb_get_intfdata(intf);
- if (!--dev-suspend_count) {
- netif_device_attach (dev-net);
+ if (!--dev-suspend_count)
tasklet_schedule (dev-bh);
- }
+
return 0;
}
EXPORT_SYMBOL_GPL(usbnet_resume);
--- a/drivers/net/usb/asix.c2007-07-30 14:18:38.0 +0200
+++ b/drivers/net/usb/asix.c2007-07-30 16:04:45.0 +0200
@@ -844,6 +844,7 @@ static int ax88172_bind(struct usbnet *d
dev-mii.phy_id_mask = 0x3f;
dev-mii.reg_num_mask = 0x1f;
dev-mii.phy_id = asix_get_phy_addr(dev);
+ dev-intf = intf;
dev-net-do_ioctl = asix_ioctl;
dev-net-set_multicast_list = ax88172_set_multicast;
@@ -969,6 +970,7 @@ static int ax88772_bind(struct usbnet *d
dev-mii.mdio_write = asix_mdio_write;
dev-mii.phy_id_mask = 0x1f;
dev-mii.reg_num_mask = 0x1f;
+ dev-intf = intf;
dev-net-do_ioctl = asix_ioctl;
dev-mii.phy_id = asix_get_phy_addr(dev);
@@ -1267,6 +1269,7 @@ static int ax88178_bind(struct usbnet *d
dev-mii.supports_gmii = 1;
dev-net-do_ioctl = asix_ioctl;
dev-mii.phy_id = asix_get_phy_addr(dev);
+ dev-intf = intf;
dev-net-set_multicast_list = asix_set_multicast;
dev-net-ethtool_ops = ax88178_ethtool_ops;
dev-net-change_mtu = ax88178_change_mtu;
@@ -1474,6 +1477,7 @@ static struct usb_driver asix_driver = {
.suspend = usbnet_suspend,
.resume = usbnet_resume,
.disconnect = usbnet_disconnect,
+ .supports_autosuspend = 1,
};
static int
Re: [linux-usb-devel] Can't unload uhci_hcd module with 2.6.22 -- also oops
Am Dienstag 31 Juli 2007 schrieb A. Kalten: On Tue, 31 Jul 2007 13:00:38 -0400 A. Kalten [EMAIL PROTECTED] wrote: But after compiling 2.6.23-rc1 and undergoing the same steps with the usb modem as before, the problem remains. The only difference is that the command rmmod uhci-hcd now reports the message Killed instead of Device busy. For whatever it's worth.I should point out that this problem only occurs when using the USB Abstract Control Model driver for USB modems (i.e. the cdc_acm module). When using my USB scanner or USB printer I can unload the uhci-hcd module without any problem using the equivalent procedure. acm uses two interfaces for one driver which is pretty rare and explains that a refcounting problem is not seen with other drivers. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for asix driver
Am Dienstag 31 Juli 2007 schrieb Alan Stern: You assign dev-intf in both the usbnet framework driver and the subdriver. Could the subdriver's assignment be removed? Yes, it is superfluous. I'll make a new patch. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Can't unload uhci_hcd module with 2.6.22 -- also oops
Am Dienstag 31 Juli 2007 schrieb Alan Stern: For whatever it's worth.I should point out that this problem only occurs when using the USB Abstract Control Model driver for USB modems (i.e. the cdc_acm module). When using my USB scanner or USB printer I can unload the uhci-hcd module without any problem using the equivalent procedure. acm uses two interfaces for one driver which is pretty rare and explains that a refcounting problem is not seen with other drivers. But shouldn't the same problem affect other people? Unloading is pretty rare. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB subsystem (part of it) hangs
Am Montag 30 Juli 2007 schrieb Paulo da Silva:
With legacy driver rt2570 the keyboard also freezes! I can't even get a
console (ctrl+alt+f1).
Using ndiswrapper only the USB or part of it breaks.
I tried, what I think - I had no feedback - ctrl+alt+prt sc+{s,u,s,b}
and got a reboot. Unfortunately there was no relevant information in the
logs. I'll try next time more 's' to see if something is written to the
log files.
In the meanwhile, I would appreciate any guidance on how to proceed to
provide you with more information.
Please get a stack trace with the t variety of the alt-sysrq you use to reboot
and post that.
Regards
Oliver
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch]yet another quirky device
Hi,
another quirky scanner.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
---
--- a/drivers/usb/core/quirks.c 2007-07-30 12:04:44.0 +0200
+++ b/drivers/usb/core/quirks.c 2007-07-30 12:05:21.0 +0200
@@ -52,6 +52,8 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x04b8, 0x011f), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* EPSON Perfection 2480 */
{ USB_DEVICE(0x04b8, 0x0121), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Seiko Epson Corp.*/
+ { USB_DEVICE(0x04b8, 0x0122), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Samsung ML-2510 Series printer */
{ USB_DEVICE(0x04e8, 0x327e), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Elsa MicroLink 56k (V.250) */
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci problem triggerable by storage
Am Samstag 28 Juli 2007 schrieb David Brownell: On Friday 27 July 2007, Alan Stern wrote: In my experience this sort of thing tends to be caused by low-level hardware communications errors. Noise in the USB data lines or a missing handshake packet, stuff like that. Not much extra debugging can be done; the 3strikes indication comes directly from the controller hardware. I did systematic testing. The hub causes it. Well, that's one theory. Thing is, this kind of problem happens more often than it should. No matter what causes it, it'd be better to recover from it ... or prevent it from happening. Nevertheless I get an IO error. Our error handling is deficient. My theory has been different: that some USB peripherals get deeply confused if Linux talks to them too fast (i.e. probably anything faster than MS-Windows). Notice how the recovery that followed involved a device reset. But -- never actually having had both a highspeed USB sniffer *AND* hardware exhibiting this problem in the same place -- I've not been able to test that theory. The hub in question is light and small. Give me your address and I'll put it in the mail. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb-serial.c question - potential Memory fault
Am Montag 30 Juli 2007 schrieb [EMAIL PROTECTED]:
This is quite dangerous :-)
You can't apply a user requested buffer_size to interrupt_buffer !
The API should only apply the buffer size to bulk buffers...
Right you are. What about this? Or do you need split sizes
for input and output?
Regards
Oliver
---
--- a/include/linux/usb/serial.h2007-07-30 12:19:39.0 +0200
+++ b/include/linux/usb/serial.h2007-07-30 12:19:46.0 +0200
@@ -201,6 +201,7 @@ static inline void usb_set_serial_data (
struct usb_serial_driver {
const char *description;
const struct usb_device_id *id_table;
+ int buffer_size;
charnum_interrupt_in;
charnum_interrupt_out;
charnum_bulk_in;
--- a/drivers/usb/serial/usb-serial.c 2007-07-30 12:20:11.0 +0200
+++ b/drivers/usb/serial/usb-serial.c 2007-07-30 12:20:15.0 +0200
@@ -866,7 +866,7 @@ int usb_serial_probe(struct usb_interfac
dev_err(interface-dev, No free urbs available\n);
goto probe_error;
}
- buffer_size = le16_to_cpu(endpoint-wMaxPacketSize);
+ buffer_size = type-buffer_size ? type-buffer_size :
le16_to_cpu(endpoint-wMaxPacketSize);
port-bulk_in_size = buffer_size;
port-bulk_in_endpointAddress = endpoint-bEndpointAddress;
port-bulk_in_buffer = kmalloc (buffer_size, GFP_KERNEL);
@@ -890,7 +890,7 @@ int usb_serial_probe(struct usb_interfac
dev_err(interface-dev, No free urbs available\n);
goto probe_error;
}
- buffer_size = le16_to_cpu(endpoint-wMaxPacketSize);
+ buffer_size = type-buffer_size ? type-buffer_size :
le16_to_cpu(endpoint-wMaxPacketSize);
port-bulk_out_size = buffer_size;
port-bulk_out_endpointAddress = endpoint-bEndpointAddress;
port-bulk_out_buffer = kmalloc (buffer_size, GFP_KERNEL);
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB subsystem (part of it) hangs
Am Montag 30 Juli 2007 schrieb Paulo da Silva: Oliver Neukum escreveu: ... Please get a stack trace with the t variety of the alt-sysrq you use to reboot and post that. I read the sysrq.txt and saw that 't' sends the output to the console! As I said, I don't have any echo from what I type. 1. The keyboard freezes or seems to freeze. 2. I have control over the mouse. Terminating the session hangs somewhere leaving the X session still active (black screen with a X cursor) however. To obtain that data I only see two ways: 1. Move back to ndiswrapper since it does not break the system. 2. Try to use /proc/sysrq-trigger from a remote connection. I don't know if the output of sysrq is sent to a remote session. I'll try this as soon as I have the next crash. It'll go to the syslog. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB Pegasus driver - avoid a potential NULL pointer dereference.
Am Sonntag 29 Juli 2007 schrieb Jesper Juhl:
On 29/07/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi,
On 7/29/07, Jesper Juhl [EMAIL PROTECTED] wrote:
Hello,
This patch makes sure we don't dereference a NULL pointer in
drivers/net/usb/pegasus.c::write_bulk_callback() in the initial
struct net_device *net = pegasus-net; assignment.
The existing code checks if 'pegasus' is NULL and bails out if
it is, so we better not touch that pointer until after that check.
[...]
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index a05fd97..04cba6b 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -768,11 +768,13 @@ done:
static void write_bulk_callback(struct urb *urb)
{
pegasus_t *pegasus = urb-context;
- struct net_device *net = pegasus-net;
+ struct net_device *net;
if (!pegasus)
return;
+ net = pegasus-net;
+
if (!netif_device_present(net) || !netif_running(net))
return;
Is it really possible that we're called into this function with
urb-context == NULL? If not, I'd suggest let's just get rid of
the check itself, instead.
I'm not sure. I am not very familiar with this code. I just figured
that moving the assignment is potentially a little safer and it is
certainly no worse than the current code, so that's a safe and
potentially benneficial change. Removing the check may be safe but I'm
not certain enough to make that call...
pegasus == NULL there would be a kernel bug. Silently ignoring
it, like the code now wants to do is bad. As the oops has never been
reported, I figure turning it into an explicit debugging test is overkill,
so removal seems to be the best option.
Regards
Oliver
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB Pegasus driver - avoid a potential NULL pointer dereference.
Am Sonntag 29 Juli 2007 schrieb [EMAIL PROTECTED]: I have the same problem in my development.. Somewhere in my code: unsigned char *data = urb-transfer_buffer ; if ( data == NULL ) dbg(%s - data is NULL !!!,__FUNCTION__ ); if ( urb-actual_length == 1 data != NULL ) len = (int) data[0]; If I don’t do this check in a usb callback function, I have kernel panic deference to null pointer ! But the fun stuff in this story is that I never see the debug data is NULL !!! so This never happen if I do this check urb-transfer_buffer is set by the caller. Usbcore should never change it. What do you set it to? Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb-storage autosuspend bug?
Am Donnerstag 26 Juli 2007 schrieb Greg KH: Alan and Oliver, was this caused by the autosuspend changes for usb-storage? The oops itself looks like refcounting. What caused the initial io error does not become clear from the log. It is possible that the device cannot stand suspension. But there's no evidence from that. On the contrary, these devices usually do an unplug/plug cycle, which is not in the log. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] ehci problem triggerable by storage
Hi, stressing a flash disk I rapidly get this error: Jul 27 12:35:00 oenone kernel: usb-storage: *** thread awakened. Jul 27 12:35:00 oenone kernel: usb-storage: Command READ_10 (10 bytes) Jul 27 12:35:00 oenone kernel: usb-storage: 28 00 00 00 25 f8 00 00 3c 00 Jul 27 12:35:00 oenone kernel: usb-storage: Bulk Command S 0x43425355 T 0x28b L 122880 F 128 Trg 0 LUN 0 CL 10 Jul 27 12:35:00 oenone kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jul 27 12:35:00 oenone kernel: usb-storage: Status code 0; transferred 31/31 Jul 27 12:35:00 oenone kernel: usb-storage: -- transfer complete Jul 27 12:35:00 oenone kernel: usb-storage: Bulk command transfer result=0 Jul 27 12:35:00 oenone kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 122880 bytes, 2 entries Jul 27 12:35:00 oenone kernel: ehci_hcd :00:02.2: devpath 3.4 ep1in 3strikes Jul 27 12:35:00 oenone kernel: usb-storage: Status code -71; transferred 8192/122880 Jul 27 12:35:00 oenone kernel: usb-storage: -- unknown error Jul 27 12:35:00 oenone kernel: usb-storage: Bulk data transfer result 0x4 Jul 27 12:35:00 oenone kernel: usb-storage: -- transport indicates error, resetting Jul 27 12:35:00 oenone kernel: usb-storage: storage_pre_reset Jul 27 12:35:00 oenone kernel: usb 3-3.4: reset high speed USB device using ehci_hcd and address 10 Jul 27 12:35:00 oenone kernel: usb_endpoint usbdev3.10_ep01: ep_device_release called for usbdev3.10_ep01 Jul 27 12:35:00 oenone kernel: usb_endpoint usbdev3.10_ep81: ep_device_release called for usbdev3.10_ep81 Jul 27 12:35:00 oenone kernel: usb-storage: storage_post_reset Jul 27 12:35:00 oenone kernel: usb-storage: usb_reset_composite_device returns 0 Jul 27 12:35:00 oenone kernel: usb-storage: scsi cmd done, result=0x7 Jul 27 12:35:00 oenone kernel: usb-storage: queuecommand called Jul 27 12:35:00 oenone kernel: usb-storage: *** thread sleeping. Jul 27 12:35:00 oenone kernel: usb-storage: *** thread awakened. Jul 27 12:35:00 oenone kernel: usb-storage: Command READ_10 (10 bytes) Jul 27 12:35:00 oenone kernel: usb-storage: 28 00 00 00 25 f8 00 00 3c 00 Jul 27 12:35:00 oenone kernel: usb-storage: Bulk Command S 0x43425355 T 0x28c L 122880 F 128 Trg 0 LUN 0 CL 10 Jul 27 12:35:00 oenone kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jul 27 12:35:00 oenone kernel: usb-storage: Status code 0; transferred 31/31 Jul 27 12:35:00 oenone kernel: usb-storage: -- transfer complete Jul 27 12:35:00 oenone kernel: usb-storage: Bulk command transfer result=0 Jul 27 12:35:00 oenone kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 122880 bytes, 2 entries Is there a way I can enable more debugging about this cause of -EPROTO? Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.23-rc1: USB hard disk broken
Am Mittwoch 25 Juli 2007 schrieb Tino Keitel: On Wed, Jul 25, 2007 at 10:24:36 +0200, Oliver Neukum wrote: Am Mittwoch 25 Juli 2007 schrieb Tino Keitel: Hi, I just tried 2.6.23-rc1 and shortly after the boot my external USB hard disk went mad. [...] Please recompile with CONFIG_USB_DEBUG set. Regards Oliver I tried, but it didn't happen again. Did you try with the old kernel again? This bug may be related to timing. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.23-rc1: USB hard disk broken
Am Mittwoch 25 Juli 2007 schrieb Tino Keitel: Hi, I just tried 2.6.23-rc1 and shortly after the boot my external USB hard disk went mad. I all started with these kernel messages: kern.info: usb 1-6: USB disconnect, address 5 kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00 kern.warn: end_request: I/O error, dev sdb, sector 68479 kern.alert: I/O error in filesystem (dm-2) meta-data dev dm-2 block 0x6c7fa20 (xfs_trans_read_buf) error 5 buf count 8192 The full kernel log can be found here: http://tikei.de/kernel.log And the config: http://tikei.de/kernel.config Needless to say that it all worked fine with 2.6.22. Please recompile with CONFIG_USB_DEBUG set. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22+: BUG: sleeping function called from invalid context at /home/jeremy/hg/xen/paravirt/linux/drivers/usb/core/urb.c:524, in_atomic():1, irqs_disabled():0
Clearly there's a bug in
drivers/usb/serial/usb-serial.c:usb_serial_put(). It shouldn't call
kref_put() while holding a spinlock.
Yes, these functions need to sleep.
Does this work?
Regards
Oliver
---
--- a/drivers/usb/serial/usb-serial.c 2007-07-23 08:47:35.0 +0200
+++ b/drivers/usb/serial/usb-serial.c 2007-07-24 09:33:15.0 +0200
@@ -60,19 +60,19 @@ static struct usb_driver usb_serial_driv
static int debug;
static struct usb_serial *serial_table[SERIAL_TTY_MINORS]; /* initially
all NULL */
-static spinlock_t table_lock;
+DEFINE_MUTEX(table_lock);
static LIST_HEAD(usb_serial_driver_list);
struct usb_serial *usb_serial_get_by_index(unsigned index)
{
struct usb_serial *serial;
- spin_lock(table_lock);
+ mutex_lock(table_lock);
serial = serial_table[index];
if (serial)
kref_get(serial-kref);
- spin_unlock(table_lock);
+ mutex_unlock(table_lock);
return serial;
}
@@ -84,7 +84,7 @@ static struct usb_serial *get_free_seria
dbg(%s %d, __FUNCTION__, num_ports);
*minor = 0;
- spin_lock(table_lock);
+ mutex_lock(table_lock);
for (i = 0; i SERIAL_TTY_MINORS; ++i) {
if (serial_table[i])
continue;
@@ -106,10 +106,10 @@ static struct usb_serial *get_free_seria
serial_table[i] = serial;
serial-port[j++]-number = i;
}
- spin_unlock(table_lock);
+ mutex_unlock(table_lock);
return serial;
}
- spin_unlock(table_lock);
+ mutex_unlock(table_lock);
return NULL;
}
@@ -172,9 +172,9 @@ static void destroy_serial(struct kref *
void usb_serial_put(struct usb_serial *serial)
{
- spin_lock(table_lock);
+ mutex_lock(table_lock);
kref_put(serial-kref, destroy_serial);
- spin_unlock(table_lock);
+ mutex_unlock(table_lock);
}
/*
@@ -1128,7 +1128,6 @@ static int __init usb_serial_init(void)
return -ENOMEM;
/* Initialize our global data */
- spin_lock_init(table_lock);
for (i = 0; i SERIAL_TTY_MINORS; ++i) {
serial_table[i] = NULL;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB Driver help needed
Am Dienstag 24 Juli 2007 schrieb Ron Gage: Anyhow, the device appears to require a non-standard function code in the URB header, code 0019. SnoopyPro (yeah, on Windows) says this function code is Vendor Endpoint. Obviously, there isn't any current way to send such a function code with the Linux USB stack. Problem is, the device will not accept the data payloads from a control message. It Please post the trace showing this feature. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22+: BUG: sleeping function called from invalid context at /home/jeremy/hg/xen/paravirt/linux/drivers/usb/core/urb.c:524, in_atomic():1, irqs_disabled():0
Clearly there's a bug in
drivers/usb/serial/usb-serial.c:usb_serial_put(). It shouldn't call
kref_put() while holding a spinlock.
As I was reminded, I polluted the namespace. Here's a better
version. Does it fix your problem?
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
---
--- a/drivers/usb/serial/usb-serial.c 2007-07-23 08:47:35.0 +0200
+++ b/drivers/usb/serial/usb-serial.c 2007-07-24 15:07:05.0 +0200
@@ -60,19 +60,19 @@ static struct usb_driver usb_serial_driv
static int debug;
static struct usb_serial *serial_table[SERIAL_TTY_MINORS]; /* initially
all NULL */
-static spinlock_t table_lock;
+static DEFINE_MUTEX(table_lock);
static LIST_HEAD(usb_serial_driver_list);
struct usb_serial *usb_serial_get_by_index(unsigned index)
{
struct usb_serial *serial;
- spin_lock(table_lock);
+ mutex_lock(table_lock);
serial = serial_table[index];
if (serial)
kref_get(serial-kref);
- spin_unlock(table_lock);
+ mutex_unlock(table_lock);
return serial;
}
@@ -84,7 +84,7 @@ static struct usb_serial *get_free_seria
dbg(%s %d, __FUNCTION__, num_ports);
*minor = 0;
- spin_lock(table_lock);
+ mutex_lock(table_lock);
for (i = 0; i SERIAL_TTY_MINORS; ++i) {
if (serial_table[i])
continue;
@@ -106,10 +106,10 @@ static struct usb_serial *get_free_seria
serial_table[i] = serial;
serial-port[j++]-number = i;
}
- spin_unlock(table_lock);
+ mutex_unlock(table_lock);
return serial;
}
- spin_unlock(table_lock);
+ mutex_unlock(table_lock);
return NULL;
}
@@ -172,9 +172,9 @@ static void destroy_serial(struct kref *
void usb_serial_put(struct usb_serial *serial)
{
- spin_lock(table_lock);
+ mutex_lock(table_lock);
kref_put(serial-kref, destroy_serial);
- spin_unlock(table_lock);
+ mutex_unlock(table_lock);
}
/*
@@ -1128,7 +1128,6 @@ static int __init usb_serial_init(void)
return -ENOMEM;
/* Initialize our global data */
- spin_lock_init(table_lock);
for (i = 0; i SERIAL_TTY_MINORS; ++i) {
serial_table[i] = NULL;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Fw: [Bugme-new] [Bug 8104] New: kernel floods console with connect-debounce failed
Am Dienstag 24 Juli 2007 schrieb Andrew Morton: guys, there have been updates to this bug via the bugzilla UI, at http://bugzilla.kernel.org/show_bug.cgi?id=8104 Hi, we need to know the oldest kernel that does not work. Please try 2.6.18 and 2.6.19 Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb_serial_suspend(): buggy(?) code
Am Montag 23 Juli 2007 schrieb Adrian Bunk:
Commit ec22559e0b7a05283a3413bda5d177e42c950e23 added the following
function to drivers/usb/serial/usb-serial.c:
[..]
The Coverity checker spotted the inconsequent NULL checking for serial.
Looking at the code it also doesn't seem to have been intended to always
return 0.
Coverity is right. The check for NULL is wrongly done and the error
return is lost.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/usb/serial/usb-serial.c 2007-07-23 08:47:35.0 +0200
+++ b/drivers/usb/serial/usb-serial.c 2007-07-23 08:49:20.0 +0200
@@ -1077,16 +1077,17 @@ int usb_serial_suspend(struct usb_interf
struct usb_serial_port *port;
int i, r = 0;
- if (serial) {
- for (i = 0; i serial-num_ports; ++i) {
- port = serial-port[i];
- if (port)
- kill_traffic(port);
- }
+ if (!serial) /* device has been disconnected */
+ return 0;
+
+ for (i = 0; i serial-num_ports; ++i) {
+ port = serial-port[i];
+ if (port)
+ kill_traffic(port);
}
if (serial-type-suspend)
- serial-type-suspend(serial, message);
+ r = serial-type-suspend(serial, message);
return r;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] iuu_phoenix new driver latency problem.... idea needed...
Am Donnerstag 19 Juli 2007 schrieb Alain Degreffe: I have a newbie question :-) I would like to have to threads: 1 reading process and one writing process... For the moment as soon I write to device, I begin to read the answer but it is not very efficient because the iso7816 don't give a real way to know if the write is finish or if the read will give an answer... In the usb-serial classical implementation, the bulk read return all incoming characters and the callback function permit to write those characters into the tty device. In my case, the problem is the next one: to read character I must send a command to the device with a bulk write.. In the read call back, may I use the port stored in the context to call a bul write function to ask to the device to read ? Yes, this no problem. You may submit URBs from a callback handler. Just use GFP_ATOMIC. Second problem, the protocol of the device works like this: To read character, I must ( as I said before ) , send a command to read ( a bulk write message ) , after try to read one byte to know how much byte are waiting in the device buffer and finally bulk read the len given at the previous step... So ideally, a thread dedicated to this sequence is the solution to the latency observed in the current implementation ( the smart routine is not magic and the cases to stop waiting are limited ) because the function wait during 200 round to be sure to read all datas... A kernel thread is overkill for that. You could use something like: 1. Send command via bulk 2. In callback of 1 - read the length byte 3. In callback of 2 - read data bytes 4. In callback of 3 - feed data to the tty layer What exactly do you mean by command? Does your device reply only when spoken to? In this case you can trigger the sequence I described above in your write() method. If the device can send data on its own, 4 should do also 1. Regards Oliver - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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]even more quirks
The number of quirky devices seems to be large.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/usb/core/quirks.c 2007-07-20 10:30:06.0 +0200
+++ b/drivers/usb/core/quirks.c 2007-07-20 11:29:55.0 +0200
@@ -30,10 +30,14 @@
static const struct usb_device_id usb_quirk_list[] = {
/* HP 5300/5370C scanner */
{ USB_DEVICE(0x03f0, 0x0701), .driver_info = USB_QUIRK_STRING_FETCH_255
},
+ /* Acer Peripherals Inc. (now BenQ Corp.) Prisa 640BU */
+ { USB_DEVICE(0x04a5, 0x207e), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Benq S2W 3300U */
{ USB_DEVICE(0x04a5, 0x20b0), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Canon, Inc. CanoScan N650U/N656U */
{ USB_DEVICE(0x04a9, 0x2206), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Canon, Inc. CanoScan 1220U */
+ { USB_DEVICE(0x04a9, 0x2207), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Canon, Inc. CanoScan N670U/N676U/LiDE 20 */
{ USB_DEVICE(0x04a9, 0x220d), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* old Cannon scanner */
@@ -42,8 +46,12 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x04b8, 0x0104), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Seiko Epson Corp. Perfection 660 */
{ USB_DEVICE(0x04b8, 0x0114), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Epson Perfection 1260 Photo */
+ { USB_DEVICE(0x04b8, 0x011d), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Seiko Epson Corp - Perfection 1670 */
{ USB_DEVICE(0x04b8, 0x011f), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* EPSON Perfection 2480 */
+ { USB_DEVICE(0x04b8, 0x0121), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Samsung ML-2510 Series printer */
{ USB_DEVICE(0x04e8, 0x327e), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Elsa MicroLink 56k (V.250) */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
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] Kingsun KS-959 USB IrDA dongle - rele ase candidate for submission (try 1)
Hi,
+struct ks959_speedparams {
+ __le32 baudrate;/* baud rate, little endian */
+ unsigned int data_bits : 2; /* data bits - 5 (5..8) */
+ unsigned int : 1;
+ unsigned int stop_bits : 1;
+ unsigned int parity_enable : 1;
+ unsigned int parity_type : 1;
+ unsigned int : 1;
+ unsigned int reset : 1;
+ __u8 reserved[3];
+} __attribute__ ((packed));
The attribute is not needed.
+/* Send a control request to change speed of the dongle */
+static int ks959_change_speed(struct ks959_cb * kingsun, unsigned speed)
+{
+ static unsigned int supported_speeds[] = {2400, 9600, 19200, 38400,
+ 57600, 115200, 576000, 1152000, 400, 0};
+ int err;
+ unsigned int i;
+
+ if (kingsun-speed_setuprequest == NULL || kingsun-speed_urb == NULL)
+ return -ENOMEM;
+
+ /* Check that requested speed is among the supported ones */
+ for (i = 0; supported_speeds[i] != 0 supported_speeds[i] != speed;
i++);
+ if (supported_speeds[i] == 0) return -EOPNOTSUPP;
+
+ memset((kingsun-speedparams), 0, sizeof(struct ks959_speedparams));
+ kingsun-speedparams.baudrate = cpu_to_le32(speed);
+ kingsun-speedparams.data_bits = 3; /* 8 data bits */
+
+ kingsun-speed_setuprequest-bRequestType = USB_DIR_OUT |
USB_TYPE_CLASS | USB_RECIP_INTERFACE;
+ kingsun-speed_setuprequest-bRequest = KINGSUN_REQ_SEND;
+ kingsun-speed_setuprequest-wValue = cpu_to_le16(0x0200);
+ kingsun-speed_setuprequest-wIndex = cpu_to_le16(0x0001);
+ kingsun-speed_setuprequest-wLength = cpu_to_le16(8);
+ usb_fill_control_urb(kingsun-speed_urb, kingsun-usbdev,
+ usb_sndctrlpipe(kingsun-usbdev, 0),
+ (unsigned char *)kingsun-speed_setuprequest,
+ (kingsun-speedparams), sizeof(struct
ks959_speedparams),
+ ks959_speed_irq, kingsun);
+ kingsun-speed_urb-status = 0;
+ err = usb_submit_urb(kingsun-speed_urb, GFP_ATOMIC);
+
+ return err;
+}
Are you sure the URB doesn't need to be waited for?
+close_irlap:
+ irlap_close(kingsun-irlap);
+free_mem:
+ if (kingsun-speed_urb) {
+ usb_free_urb(kingsun-speed_urb);
+ kingsun-speed_urb = NULL;
+ }
+ if (kingsun-tx_urb) {
+ usb_free_urb(kingsun-tx_urb);
+ kingsun-tx_urb = NULL;
+ }
+ if (kingsun-rx_urb) {
+ usb_free_urb(kingsun-rx_urb);
+ kingsun-rx_urb = NULL;
+ }
+ if (kingsun-rx_unwrap_buff.skb) {
+ kfree_skb(kingsun-rx_unwrap_buff.skb);
+ kingsun-rx_unwrap_buff.skb = NULL;
+ kingsun-rx_unwrap_buff.head = NULL;
+ }
+ return err;
+}
usb_free_urb() can take NULL.
+static int ks959_net_close(struct net_device *netdev)
+{
+ struct ks959_cb *kingsun = netdev_priv(netdev);
+
+ /* Stop transmit processing */
+ netif_stop_queue(netdev);
+
+ /* Mop up receive transmit urb's */
+ usb_kill_urb(kingsun-speed_urb);
+ usb_kill_urb(kingsun-tx_urb);
+ usb_kill_urb(kingsun-rx_urb);
Race condition. You must kill the tx_urb first, as it can submit the speed_urb
Regards
Oliver
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iuu_phoenix new driver proposal 2
Am Mittwoch 18 Juli 2007 schrieb Alain Degreffe:
+static int iuu_tiocmget(struct usb_serial_port *port, struct file *file)
+{
+ u8 *st;
+ int status ;
+ st = kmalloc(sizeof(u8), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM ;
+ iuu_status(port, st);
+
+ dbg(%s (%d) msg , __FUNCTION__, port-number);
+ if (st[0] IUU_FULLCARD_IN) {
+ dbg(%s card present ! value returned %i , __FUNCTION__,
+ TIOCM_CD);
+ status = 0 ;
+ } else {
+ status TIOCM_CD;
Could you make the code compileable and resubmit it?
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch]more quirky devices
Hi,
our list of devices which cannot be suspended keeps growing.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- greg26/drivers/usb/core/quirks.c~ 2007-07-19 08:55:26.0 +0200
+++ greg26/drivers/usb/core/quirks.c2007-07-19 09:52:48.0 +0200
@@ -32,8 +32,16 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x03f0, 0x0701), .driver_info = USB_QUIRK_STRING_FETCH_255
},
/* Benq S2W 3300U */
{ USB_DEVICE(0x04a5, 0x20b0), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Canon, Inc. CanoScan N650U/N656U */
+ { USB_DEVICE(0x04a9, 0x2206), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Canon, Inc. CanoScan N670U/N676U/LiDE 20 */
+ { USB_DEVICE(0x04a9, 0x220d), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* old Cannon scanner */
+ { USB_DEVICE(0x04a9, 0x2220), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Seiko Epson Corp. Perfection 1200 */
{ USB_DEVICE(0x04b8, 0x0104), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Seiko Epson Corp. Perfection 660 */
+ { USB_DEVICE(0x04b8, 0x0114), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Seiko Epson Corp - Perfection 1670 */
{ USB_DEVICE(0x04b8, 0x011f), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Samsung ML-2510 Series printer */
@@ -42,6 +50,8 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x05cc, 0x2267), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Ultima Electronics Corp.*/
{ USB_DEVICE(0x05d8, 0x4005), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Agfa Snapscan1212u */
+ { USB_DEVICE(0x06bd, 0x2061), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Umax [hex] Astra 3400U */
{ USB_DEVICE(0x1606, 0x0060), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iuu_phoenix new driver proposal 2 fixed
Am Donnerstag 19 Juli 2007 schrieb [EMAIL PROTECTED]:
OOps ;-)
2 missing characters...
Now it compile without warning or error
+ /* shutdown our urbs */
+ dbg(%s - shutting down urbs, __FUNCTION__);
+ result = usb_unlink_urb(port-write_urb);
+ if (result)
+ dbg(%s - usb_unlink_urb (write_urb)
+failed with reason: %d, __FUNCTION__, result);
+
+ result = usb_unlink_urb(port-read_urb);
+ if (result)
+ dbg(%s - usb_unlink_urb (read_urb)
+ failed with reason: %d, __FUNCTION__, result);
+
+ result = usb_unlink_urb(port-interrupt_in_urb);
+ if (result)
+ dbg(%s - usb_unlink_urb (voiderrupt_in_urb)
+failed with reason: %d, __FUNCTION__, result);
You must use usb_kill_urb() here.
+ serial = port-serial;
+ if (!serial)
+ return;
+ iuu_led(port, 0, 0, 0xF000, 0xFF);
+ dbg(%s - port %d, __FUNCTION__, port-number);
+
+ iuu_uart_off(port);
+ if (serial-dev) {
If serial-dev can be NULL, you must not use iuu_led unconditionally.
+static int iuu_uart_on(struct usb_serial_port *port)
+{
+ int status;
+ u8 *buf;
+
+ buf = kmalloc(sizeof(u8) * 4, GFP_KERNEL);
A simple 4 will do.
+ tmp = kmalloc(sizeof(struct iuu_buffers), GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
+
+ /* u_int8_t datain[256]; */
+
+ if (iuu_led(port, 0xF000, 0, 0, 0xFF) 0) {
+ kfree(tmp);
+ return -EIO;
+ }
+
+ for (i = 0; i 2; i++) {
+ status = bulk_immediate(port, rxcmd, 1);
+ if (status != IUU_OPERATION_OK) {
+ dbg(%s - uart_flush_write error, __FUNCTION__);
+ return status;
+ }
Memory leak in error case
+ if (tmp-len 0) {
+ /* test buffer overflow */
+ if (curpos + tmp-len 256) {
+ kfree(tmp);
+ return -1;
What is -1 supposed to mean?
+ if (priv-write_busy)
+ return -1;
+
+ tmp = kmalloc(sizeof(struct iuu_buffers), GFP_KERNEL);
+ if (!tmp)
+ return -EIO;
+
+ priv-write_busy = 1;
This is a race condition. More than one task can succeed the test and proceed.
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] usbfs and reset_resume()
Hi, it seems to me that some drivers, in particular usbfs cdc-acm are unable to implement reset_resume() because they don't know the device state. So what would be the correct response if the system is put to sleep while any of these drivers is bound to a device that has the RESET_RESUME quirk? It seems to me that it should be treated like disconnect()? What do you think? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Don't let usb-storage steal Blackberry Pearl
Am Donnerstag 19 Juli 2007 schrieb Jeremy Katz: +/* Jeremy Katz [EMAIL PROTECTED]: + * The Blackberry Pearl can run in two modes; a usb-storage only mode + * and a mode that allows access via mass storage and to its database. + * The berry_charge module will set the device to dual mode and thus we + * should ignore its native mode if that module is built Does it change the ID? If not, how do you access the mass storage part after berry_charge has run? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Don't let usb-stor age steal Blackberry Pearl
Am Donnerstag 19 Juli 2007 schrieb Jeremy Katz: On Thu, 2007-07-19 at 15:45 +0200, Oliver Neukum wrote: Am Donnerstag 19 Juli 2007 schrieb Jeremy Katz: +/* Jeremy Katz [EMAIL PROTECTED]: + * The Blackberry Pearl can run in two modes; a usb-storage only mode + * and a mode that allows access via mass storage and to its database. + * The berry_charge module will set the device to dual mode and thus we + * should ignore its native mode if that module is built Does it change the ID? If not, how do you access the mass storage part after berry_charge has run? After berry_charge has run, it shows up as a different ID with two different end-points -- one for mass-storage, the other for the Blackberry communication OK, I see. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] Moving from pipes to usb_host_endpoint pointers
Am Mittwoch 18 Juli 2007 schrieb Alan Stern:
int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
{
- int pipe, temp, max;
- struct usb_device *dev;
- int is_out;
+ int xfertype, max;
+ struct usb_device *dev;
+ struct usb_host_endpoint*ep;
+ int is_out;
This is a bit odd. Using a pointer the direction info should be included.
Or you could use endpoint numbers, which would remove some issues
with enummeration.
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] Moving from pipes to usb_host_endpoint pointers
Am Mittwoch 18 Juli 2007 schrieb Alan Stern:
On Wed, 18 Jul 2007, Oliver Neukum wrote:
Am Mittwoch 18 Juli 2007 schrieb Alan Stern:
int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
{
- int pipe, temp, max;
- struct usb_device *dev;
- int is_out;
+ int xfertype, max;
+ struct usb_device *dev;
+ struct usb_host_endpoint*ep;
+ int is_out;
This is a bit odd. Using a pointer the direction info should be included.
I don't understand. Included where?
struct usb_host_endpoint
Or you could use endpoint numbers, which would remove some issues
with enummeration.
That's essentially the same as using a pipe, since some of the bits in
a pipe _are_ the endpoint number.
Only some, but yes, it is much closer. Still if you give ep, dev and is_out
should be implicit. And how do you submit the first URBs? Are you going
to fake a struct usb_host_endpoint for endpoint 0 ?
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iuu_phoenix new driver proposal for review and comments
Am Mittwoch 18 Juli 2007 schrieb eczema:
+struct iuu_buffers {
+ u8 buf[256];
+ u8 finalbuf[256];
+ u8 dbgbuf[512];
+ u8 len;
+};
+
Is that safe? Kmalloc will give out chunks of memory safe for DMA, but will
they be aligned?
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] iuu_phoenix new driver proposal for review and comments
Am Mittwoch 18 Juli 2007 schrieb eczema:
+ if ((set == 0) priv-TIOSTATUS == TIOCM_RTS) {
+ dbg(%s TIOCMSET RESET called !!!, __FUNCTION__);
+ priv-TIOSTATUS = 0;
+ if (iuu_reset(port, 0x0C))
+ return -EIO;
+ current-state = TASK_INTERRUPTIBLE;
+ schedule_timeout(1 + 500 * HZ / 1000);
If you are really interrupted, you'll break the time requirements.
+static int iuu_tiocmget(struct usb_serial_port *port, struct file *file)
+{
+ u8 *st;
+ st = kmalloc(sizeof(u8), GFP_KERNEL);
+ iuu_status(port, st);
kmalloc() can fail.
+ if (st[0] IUU_FULLCARD_IN) {
+ dbg(%s card present ! value returned %i , __FUNCTION__,
+ TIOCM_CD);
+ kfree(st);
+ return 0;
+ } else {
+ kfree(st);
+ return TIOCM_CD;
+ }
You might unify the cleanup
+iuu_ioctl(struct usb_serial_port *port, struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+
+ int mask;
+
+ dbg(%s (%d) cmd = 0x%04x, __FUNCTION__, port-number, cmd);
+
+ get_user(mask, (unsigned long *)arg);
This can fail
+ case TCFLSH:
+ return (-1);
Meaning what?
+ if (priv-write_busy)
+ return -1;
What for if you don't ever read write_busy?
+ tty-low_latency = 1;
Should be done in probe()
+ dbg(%s - port %d, __FUNCTION__, port-number);
+ usb_clear_halt(serial-dev, port-write_urb-pipe);
+ usb_clear_halt(serial-dev, port-read_urb-pipe);
Is this really needed?
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 01/02] USB: sierra: Add TRU-Install (c) Support [ATTEMPT 4]
Am Freitag 13 Juli 2007 schrieb Kevin Lloyd:
+int sierra_probe(struct usb_interface *iface, const struct usb_device_id *id)
+{
+ int result;
+ struct usb_device *udev;
+
+ udev = usb_get_dev(interface_to_usbdev(iface));
+
+ /* Check if in installer mode */
+ if (id-driver_info == DEVICE_INSTALLER){
+ dev_dbg(udev-dev, %s, FOUND DEVICE(SW)\n);
+ result = sierra_set_ms_mode(udev, SWIMS_SET_MODE_Modem);
+ return result;
As I mentioned, you'd better return -EIO here. You don't want to bind
to the device, as it is not yet a serial device and you want the driver core
to stop trying while it goes away and transforms itself.
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Bugme-new] [Bug 8746] New: 3G USB HUAWEI E220 gsm modem
Am Freitag 13 Juli 2007 schrieb Andrew Morton: T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 7 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=12d1 ProdID=1003 Rev= 0.00 S: Manufacturer=HUAWEI Technologies S: Product=HUAWEI Mobile C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms This thing is a storage device but a serial driver binds to it. Most likely this is one of those who emulate a CD to install drivers under another OS. You need to know the trick which switches is to the modem mode. Contact the manufacturer, we cannot help you. Failing that, this needs reverse engineering. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] HID driver
Am Donnerstag, 12. Juli 2007 schrieb Marcel Meerstetter: Hello all, i need help with the USB HID driver. I am running kernel version 2.6.12. When I attach a USB keyboard, it is recognized # usb 1-1: new low speed USB device using s3c2410-ohci and address 2 usb 1-1: Product: HP Basic USB Keyboard usb 1-1: Manufacturer: CHICONY however no device is created under /dev. As a result, I can also not open the device and read what is being entered. I have looked into the HID code, but don't see any place where a device name is given. When I press a key, however, the driver does respond and I track the response all the way to input_event() in input.c. What I would like to is for my user-space application to receive the input , i.e. be able to read the key that was pressed. Under Ubuntu kernel 2.6.17, the device works fine. The kernel doesn't make device nodes. Do you have udev properly installed? Is your udev version able to work with a kernel that old? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch]minimal autosuspend support for USB HID devices
Hi,
autosuspend for USB HID devices remains problematic as far as mice
and keyboards are concerned. While I am working on a grand solution,
here's a minimalist patch that works for those devices not continously
in use. It'll work for joystick and some other devices.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--- a/drivers/hid/usbhid/hid-core.c 2007-07-11 10:02:44.0 +0200
+++ b/drivers/hid/usbhid/hid-core.c 2007-07-11 10:02:54.0 +0200
@@ -506,7 +506,16 @@ static int hid_get_class_descriptor(stru
int usbhid_open(struct hid_device *hid)
{
- ++hid-open;
+ struct usbhid_device *usbhid = hid-driver_data;
+ int res;
+
+ if (!hid-open++) {
+ res = usb_autopm_get_interface(usbhid-intf);
+ if (res 0) {
+ hid-open--;
+ return -EIO;
+ }
+ }
if (hid_start_in(hid))
hid_io_error(hid);
return 0;
@@ -516,8 +525,10 @@ void usbhid_close(struct hid_device *hid
{
struct usbhid_device *usbhid = hid-driver_data;
- if (!--hid-open)
+ if (!--hid-open) {
usb_kill_urb(usbhid-urbin);
+ usb_autopm_put_interface(usbhid-intf);
+ }
}
/*
@@ -1097,6 +1108,7 @@ static struct usb_driver hid_driver = {
.pre_reset =hid_pre_reset,
.post_reset = hid_post_reset,
.id_table = hid_usb_ids,
+ .supports_autosuspend = 1,
};
static int __init hid_init(void)
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New driver proposal: iuu_phoenix
Am Mittwoch, 11. Juli 2007 schrieb Alain Degreffe: Hi, I try to make a new driver for infinity unlimited usb. I use the usbserial layer to manage the lowlevel functions like probing or ttyUSBx creation/selection. The driver works but only after a first sequence open and close of the device by a program in the user space. After this first open/close The obvious candidate would be the call to iuu_uart_off() which you do in iuu_close(). Possibly the device needs on off/on-sequence to work. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New driver proposal: iuu_phoenix
Am Mittwoch, 11. Juli 2007 schrieb Alain Degreffe:
sequence, all is running well. I join the (hugly ?) code for a review. I'm a
1. you violate the kernel coding style (look into the Documentation directory)
2. you should use a .h file for your defines
3.:
static int
iuu_startup (struct usb_serial *serial)
{
struct iuu_private *priv;
int i;
for (i = 0; i serial-num_ports; ++i) {
priv = kmalloc (sizeof (struct iuu_private), GFP_KERNEL);
if (!priv)
return -ENOMEM;
You are setting a trap here. You have only one port, but you are using
a loop. Yet, should you ever need it, you have a memory leak in the error
case.
4.:
if ((set == 0) priv-TIOSTATUS == TIOCM_RTS) {
dbg (%s TIOCMSET RESET called !!!, __FUNCTION__);
priv-TIOSTATUS = 0;
iuu_reset (port, 0x0C);
current-state = TASK_INTERRUPTIBLE;
schedule_timeout (1 + 500 * HZ / 1000);
iuu_uart_read_and_store (port);
}
If you need a delay, do it explicitely. You might be woken up prematurely.
5.:
static int
iuu_ioctl (struct usb_serial_port *port, struct file *file, unsigned int cmd,
unsigned long arg)
{
int mask;
dbg (%s (%d) cmd = 0x%04x, __FUNCTION__, port-number, cmd);
get_user (mask, (unsigned long *) arg);
This may fail. You need to handle errors.
6.:
static int
iuu_reset (struct usb_serial_port *port, u_int8_t wt)
{
int status;
u_int8_t buf[4];
status = iuu_uart_flush (port);
if (status != IUU_OPERATION_OK) {
dbg (%s - reset (flush) error , __FUNCTION__);
return status;
}
buf[0] = IUU_RST_SET;
buf[1] = IUU_DELAY_MS;
buf[2] = wt; /* miliseconds */
buf[3] = IUU_RST_CLEAR;
status = bulk_immediate (port, buf, 4);
DMA on the stack is not allowed. buf[4] must be kmalloced.
7.:
/* send the data out the bulk port */
priv-im_write_busy = 1;
This variable is never read.
8.:
static int
read_immediate (struct usb_serial_port *port, unsigned char *buf, int count)
{
int status;
struct usb_serial *serial = port-serial;
Do you real want to throw away actual?
9.:
int
iuu_led (struct usb_serial_port *port, u_int16_t R, u_int16_t G, u_int16_t B,
u_int8_t f)
{
int status;
u_int8_t buf[8];
No DMA on the stack. And you might define a structure for that.
10.:
if (priv-write_busy)
return -1;
/*
if ( priv-loop 2000) {
dbg(%s - loop detected , __FUNCTION__);
return 0;
}
*/
priv-write_busy = 1;
This is a race condition right out of the textbook.
And there are other similar errors. I'll be happy to do another review after
you'll have fixed the issues I've pointed out.
HTH
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New driver proposal: iuu_phoenix
Am Mittwoch, 11. Juli 2007 schrieb Alain Degreffe: Mmmh, I don't think so because ,because in the debug, after the insmod, if I open the device, the debug is normal. The problem seems to be the flip buffer that don't work well.The flush function don't give any char to the userland... Do you see the data with usbmon? Have you tried: port-tty-low_latency = 1; Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch]autosuspend for cdc-acm
Hi,
this implements autosuspend for cdc-acm devices.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/usb/class/cdc-acm.c 2007-06-11 13:27:17.0 +0200
+++ b/drivers/usb/class/cdc-acm.c 2007-05-30 20:56:00.0 +0200
@@ -330,26 +330,26 @@ static void acm_read_bulk(struct urb *ur
return;
if (status)
- dev_dbg(acm-data-dev, bulk rx status %d, status);
+ dev_dbg(acm-data-dev, bulk rx status %d\n, status);
buf = rcv-buffer;
buf-size = urb-actual_length;
+ spin_lock(acm-read_lock);
if (likely(status == 0)) {
- spin_lock(acm-read_lock);
list_add_tail(rcv-list, acm-spare_read_urbs);
list_add_tail(buf-list, acm-filled_read_bufs);
- spin_unlock(acm-read_lock);
} else {
/* we drop the buffer due to an error */
- spin_lock(acm-read_lock);
list_add_tail(rcv-list, acm-spare_read_urbs);
list_add(buf-list, acm-spare_read_bufs);
- spin_unlock(acm-read_lock);
/* nevertheless the tasklet must be kicked unconditionally
so the queue cannot dry up */
}
- tasklet_schedule(acm-urb_task);
+
+ if (!acm-suspending)
+ tasklet_schedule(acm-urb_task);
+ spin_unlock(acm-read_lock);
}
static void acm_rx_tasklet(unsigned long _acm)
@@ -835,7 +835,7 @@ static int acm_probe (struct usb_interfa
if (!buflen) {
if (intf-cur_altsetting-endpoint-extralen
intf-cur_altsetting-endpoint-extra) {
- dev_dbg(intf-dev,Seeking extra descriptors on
endpoint);
+ dev_dbg(intf-dev,Seeking extra descriptors on
endpoint\n);
buflen = intf-cur_altsetting-endpoint-extralen;
buffer = intf-cur_altsetting-endpoint-extra;
} else {
@@ -885,24 +885,24 @@ next_desc:
if (!union_header) {
if (call_interface_num 0) {
- dev_dbg(intf-dev,No union descriptor, using call
management descriptor);
+ dev_dbg(intf-dev,No union descriptor, using call
management descriptor\n);
data_interface = usb_ifnum_to_if(usb_dev,
(data_interface_num = call_interface_num));
control_interface = intf;
} else {
- dev_dbg(intf-dev,No union descriptor, giving up);
+ dev_dbg(intf-dev,No union descriptor, giving up\n);
return -ENODEV;
}
} else {
control_interface = usb_ifnum_to_if(usb_dev,
union_header-bMasterInterface0);
data_interface = usb_ifnum_to_if(usb_dev, (data_interface_num =
union_header-bSlaveInterface0));
if (!control_interface || !data_interface) {
- dev_dbg(intf-dev,no interfaces);
+ dev_dbg(intf-dev,no interfaces\n);
return -ENODEV;
}
}
if (data_interface_num != call_interface_num)
- dev_dbg(intf-dev,Seperate call control interface. That is
not fully supported.);
+ dev_dbg(intf-dev,Seperate call control interface. That is
not fully supported.\n);
skip_normal_probe:
@@ -910,7 +910,7 @@ skip_normal_probe:
if (data_interface-cur_altsetting-desc.bInterfaceClass !=
CDC_DATA_INTERFACE_TYPE) {
if (control_interface-cur_altsetting-desc.bInterfaceClass ==
CDC_DATA_INTERFACE_TYPE) {
struct usb_interface *t;
- dev_dbg(intf-dev,Your device has switched
interfaces.);
+ dev_dbg(intf-dev,Your device has switched
interfaces.\n);
t = control_interface;
control_interface = data_interface;
@@ -921,7 +921,7 @@ skip_normal_probe:
}
if (usb_interface_claimed(data_interface)) { /* valid in this context */
- dev_dbg(intf-dev,The data interface isn't available);
+ dev_dbg(intf-dev,The data interface isn't available\n);
return -EBUSY;
}
@@ -938,7 +938,7 @@ skip_normal_probe:
if (!usb_endpoint_dir_in(epread)) {
/* descriptors are swapped */
struct usb_endpoint_descriptor *t;
- dev_dbg(intf-dev,The data interface has switched endpoints);
+ dev_dbg(intf-dev,The data interface has switched
endpoints\n);
t = epread;
epread = epwrite;
@@ -1143,11 +1143,60 @@ static void acm_disconnect(struct usb_in
}
mutex_unlock(open_mutex);
-
if (acm-tty)
tty_hangup(acm-tty);
}
+static int acm_suspend (struct
Re: [linux-usb-devel] What's the difference between async and sync unlink?
Am Mittwoch, 11. Juli 2007 schrieb jidong xiao: I see there are two routines, usb_unlink_urb and usb_kill_urb,the latter one should be used for sync unlinking,this means it can go to sleep,it won't return until the completion handler have finished.And the former one could not go to sleep.But what's difference between sync and async,I mean,why do we need such two kinds of mechanism to cancel a transfer request? Under some conditions, eg. network drivers' and the storage driver's timeout handling, drivers cannot sleep. They have to stop transfers asynchronously. I can find there are such comments in the source code, * When the URB_ASYNC_UNLINK transfer flag for the URB is set, this * request is asynchronous. Success is indicated by returning -EINPROGRESS, * at which time the URB will normally have been unlinked but not yet * given back to the device driver. When it is called, the completion * function will see urb-status == -ECONNRESET. my question is, what would happen if urb-status==-ECONNRESET? The driver then knows that an URB was stopped prematurely and the transfer must be unconsidered incomplete. What exactly must be done depends on why the driver called usb_unlink_urb() I am sorry for this somewhat generic answer. Your question is not specific enough. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] What's the difference between async and sync unlink?
Am Mittwoch, 11. Juli 2007 schrieb jidong xiao: On 7/11/07, Oliver Neukum [EMAIL PROTECTED] wrote: Am Mittwoch, 11. Juli 2007 schrieb jidong xiao: I see there are two routines, usb_unlink_urb and usb_kill_urb,the latter one should be used for sync unlinking,this means it can go to sleep,it won't return until the completion handler have finished.And the former one could not go to sleep.But what's difference between sync and async,I mean,why do we need such two kinds of mechanism to cancel a transfer request? Under some conditions, eg. network drivers' and the storage driver's timeout handling, drivers cannot sleep. They have to stop transfers asynchronously. Ok,let's talk about the timeout handling routine,we defined a timeout_handler in drivers/usb/storage/transport.c,inside that function,we will call usb_unlink_urb,why cannot we sleep?what impact if the driver go to sleep here? The handler is called with a spinlock held. If you sleep and another task tries to take the same lock, you will get a deadlock. This is the general reason for being unable to sleep in USB drivers. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch]autosuspend for cdc-acm
Am Mittwoch, 11. Juli 2007 schrieb Alan Stern: On Wed, 11 Jul 2007, Oliver Neukum wrote: Hi, this implements autosuspend for cdc-acm devices. Do you mean it adds support for plain old suspend/resume? It definitely does not implement autosuspend. Damn, I wanted to submit both changes and somehow got into the wrong directory with the old version. Greg, please disregard that patch. I need to check what directory has which version and I'll resubmit. Thanks confused Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch]minimal autosuspend support for USB HID devices
Am Mittwoch, 11. Juli 2007 schrieb Alan Stern: On Wed, 11 Jul 2007, Jiri Kosina wrote: On Wed, 11 Jul 2007, Oliver Neukum wrote: autosuspend for USB HID devices remains problematic as far as mice and keyboards are concerned. While I am working on a grand solution, here's a minimalist patch that works for those devices not continously in use. Hi Oliver, I like this patch until the ultimate solution comes (if there is any at all). Thanks, I agree. It's nice and simple. It's an admission of failure :-(. At least temporarily. Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 01/02] Sierra Wireless - Add TRU-Install (c) Support
Am Donnerstag, 12. Juli 2007 schrieb Kevin Lloyd:
From: Kevin Lloyd [EMAIL PROTECTED]
This patch adds compatibility with Sierra Wireless' new TRU-Install feature.
Future devices that use this feature will not work unless this patch has been
applied.
Is this some type of CD-ROM simulation to provide drivers?
+int sierra_probe(struct usb_interface *iface, const struct usb_device_id *id)
+{
+ int result;
+ struct usb_device *udev;
+
+ udev = usb_get_dev(interface_to_usbdev(iface));
+
+ /* Check if in installer mode */
+ if (id-driver_info == DEVICE_INSTALLER){
+ dev_dbg(FOUND DEVICE(SW)\n);
+ result = sierra_set_ms_mode(udev, SWIMS_SET_MODE_Modem);
+ return 0;
This is not a good idea in the long run. If you don't return an error here,
disconnect() will be called for your driver and will have to deal with
a semiinitialized device.
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch]additions to the quirk list
Hi,
this adds some scanners reported to be crashed by autosuspend to
the quirk list.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- a/drivers/usb/core/quirks.c 2007-07-10 12:55:56.0 +0200
+++ b/drivers/usb/core/quirks.c 2007-07-10 12:56:04.0 +0200
@@ -30,11 +30,18 @@
static const struct usb_device_id usb_quirk_list[] = {
/* HP 5300/5370C scanner */
{ USB_DEVICE(0x03f0, 0x0701), .driver_info = USB_QUIRK_STRING_FETCH_255
},
+ /*Benq S2W 3300U */
+ { USB_DEVICE(0x04a5, 0x20b0), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Seiko Epson Corp. Perfection 1200 */
+ { USB_DEVICE(0x04b8, 0x0104), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Seiko Epson Corp - Perfection 1670 */
{ USB_DEVICE(0x04b8, 0x011f), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Elsa MicroLink 56k (V.250) */
{ USB_DEVICE(0x05cc, 0x2267), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
-
+ /* Ultima Electronics Corp.*/
+ { USB_DEVICE(0x05d8, 0x4005), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Umax [hex] Astra 3400U */
+ { USB_DEVICE(0x1606, 0x0060), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
{ } /* terminating entry must be last */
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 1/2] USB: add usb_autopm_get_interface_burst()
Am Freitag, 6. Juli 2007 schrieb Alan Stern: This patch (as929) adds usb_autopm_get_interface_burst() to the autosuspend programming interface. It is intended for situations where I/O events occur in bursts of activity; it reduces overhead by not cancelling the device's autosuspend timer. Do you have numbers on how many del/mod_timer cycles you need to outweigh one timer firing needlessly? Under which circumstances should this API be used? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 2/2] usb-storage: implement autosuspend
Am Freitag, 6. Juli 2007 schrieb Alan Stern: @@ -1028,6 +1039,7 @@ static int storage_probe(struct usb_inte * start it up. */ scsi_host_get(us_to_host(us)); atomic_inc(total_threads); + usb_autopm_get_interface(intf); /* dropped in the scanning thread */ wake_up_process(th); return 0; It seems to me that we should fail probe() if usb_autopm_get_interface() fails here. Other than that I obviously like it. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 1/2] USB: add usb_autopm_get_interface_burst()
Am Montag, 9. Juli 2007 schrieb Alan Stern: On Mon, 9 Jul 2007, Oliver Neukum wrote: Am Freitag, 6. Juli 2007 schrieb Alan Stern: This patch (as929) adds usb_autopm_get_interface_burst() to the autosuspend programming interface. It is intended for situations where I/O events occur in bursts of activity; it reduces overhead by not cancelling the device's autosuspend timer. Do you have numbers on how many del/mod_timer cycles you need to outweigh one timer firing needlessly? Under which circumstances should this API be used? I don't have any hard numbers. In fact, I can't even think of a good way to get them. Do you have any suggestions? How about reading from a flash drive and measuring CPU utilization? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] changing URB allocation API
Am Freitag, 6. Juli 2007 schrieb Alan Stern: On Fri, 6 Jul 2007, Oliver Neukum wrote: Hi, I tried switching our allocation APIs to: struct urb *usb_alloc_urb(struct usb_host_endpoint *ep, size_t alloc_length, gfp_t mem_flags); struct urb *usb_alloc_iso_urb(struct usb_host_endpoint *ep, unsigned int iso_packets, gfp_t mem_flags); Unfortunately during initialisation ep-ep_dev turns out to be NULL. Should I change the allocator or the initialisation? That's a real problem. During initial enumeration the usb_device hasn't been registered yet, so the ep_device hasn't been created. One possibility is to add yet another allocator: struct urb *usb_alloc_ep0_urb(struct usb_device *udev, size_t alloc_length, gfp_t mem_flags); Very well. Given the call chain this means changing the API of the usb_*_msg() calls to pass in an URB. If I do that I'll preallocate an URB per device for usbcore's calls to ep0 to make sure we won't face ENOMEM in some very awkward situations. This could have an additional extra use, since it could leave space for the setup packet at the end of the URB (rounded up to the next cache line). That collides with the HCD allocating the URB, or it means also changing the HCD interface and adding a method just for this. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
Am Samstag, 7. Juli 2007 schrieb David Brownell: On Saturday 07 July 2007, Alan Stern wrote: On Fri, 6 Jul 2007, David Brownell wrote: The total number of interrupts would depend on the HCD. Right now OHCI is probably the worst case. Worst??? No, I'd say it's intermediate between UHCI (lots of IRQs) and EHCI (can have virtually none). Is ehci-hcd really capable of doing that? Yes; submit a big scatterlist of 128 KBytes, and unless there's some other controller operation going on at the same time there won't be an IRQ until the very last packet completes. This is very good and worth preserving. IMHO the storage driver should be optimized for EHCI. The others must work, but the most important is EHCI. So this would point to dynamic allocation of URBs with one preallocated URB to fall back to for the ENOMEM case. This brings me to an idea. Is it possible to accept the next scsi request while the current request is being executed? That way, when the first request finishes, the URBs could be retained if they are needed right away and otherwise freed. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] changing URB allocation API
Am Samstag, 7. Juli 2007 schrieb Alan Stern: On Sat, 7 Jul 2007, Oliver Neukum wrote: That's a real problem. During initial enumeration the usb_device hasn't been registered yet, so the ep_device hasn't been created. One possibility is to add yet another allocator: struct urb *usb_alloc_ep0_urb(struct usb_device *udev, size_t alloc_length, gfp_t mem_flags); Very well. Given the call chain this means changing the API of the usb_*_msg() calls to pass in an URB. Don't change the existing API. Make usb_control_msg() allocate an URB and a setup packet buffer, and add a new intermediate routine which takes them as arguments. Then code using a preallocated URB can call the intermediate routine directly. Good idea. It shall be done. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
Am Samstag, 7. Juli 2007 schrieb Alan Stern: This brings me to an idea. Is it possible to accept the next scsi request while the current request is being executed? That way, when the first request finishes, the URBs could be retained if they are needed right away and otherwise freed. It's _possible_, but why go through all that work? Just keep the URBs allocated permanently. They don't take up much space compared with UHCI's TDs. I was hoping to keep everything, not just the URBs. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] changing URB allocation API
Hi,
I tried switching our allocation APIs to:
struct urb *usb_alloc_urb(struct usb_host_endpoint *ep, size_t alloc_length,
gfp_t mem_flags);
struct urb *usb_alloc_iso_urb(struct usb_host_endpoint *ep, unsigned int
iso_packets, gfp_t mem_flags);
Unfortunately during initialisation ep-ep_dev turns out to be NULL.
Should I change the allocator or the initialisation?
Regards
Oliver
[ cut here ]
Jul 6 14:17:48 valisk kernel: kernel BUG at drivers/usb/core/urb.c:63!
Jul 6 14:17:48 valisk kernel: invalid opcode: [1] SMP
Jul 6 14:17:48 valisk kernel: CPU 0
Jul 6 14:17:48 valisk kernel: Modules linked in: ohci_hcd usbcore af_packet
cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave
powernow_k8 freq_table snd_pcm_o
ss snd_mixer_oss snd_seq snd_seq_device bay dock button battery ac dm_mod
atiixp pcmcia generic snd_atiixp firewire_ohci bcm43xx firewire_core crc_itu_t
snd_ac97_codec nsc_ircc ohci13
94 ac97_bus ieee1394 firmware_class ide_core irda tifm_7xx1 snd_pcm
ieee80211softmac crc_ccitt tifm_core snd_timer yenta_socket rsrc_nonstatic
ieee80211 tg3 rtc_cmos rtc_core rtc_lib
snd pcmcia_core ieee80211_crypt k8temp hwmon soundcore snd_page_alloc i2c_piix4
i2c_core shpchp pci_hotplug joydev parport_pc lp parport edd fan thermal
processor
Jul 6 14:17:48 valisk kernel: Pid: 3557, comm: insmod Not tainted
2.6.22-rc7-nomem-default #14
Jul 6 14:17:48 valisk kernel: RIP: 0010:[883a761f]
[883a761f] :usbcore:usb_alloc_urb+0x16/0x9f
Jul 6 14:17:48 valisk kernel: RSP: 0018:81002da51bc8 EFLAGS: 00010246
Jul 6 14:17:48 valisk kernel: RAX: RBX: 8100381d8bc0 RCX:
0080
Jul 6 14:17:48 valisk kernel: RDX: 0010 RSI: 0012 RDI:
81002da35048
Jul 6 14:17:48 valisk kernel: RBP: 0012 R08: 0100 R09:
81002da35048
Jul 6 14:17:48 valisk kernel: R10: 81003e0690c0 R11: 8043a340 R12:
fff4
Jul 6 14:17:48 valisk kernel: R13: R14: 0012 R15:
0080
Jul 6 14:17:48 valisk kernel: FS: 2b37467ea6f0()
GS:80571000() knlGS:
Jul 6 14:17:48 valisk kernel: CS: 0010 DS: ES: CR0: 8005003b
Jul 6 14:17:48 valisk kernel: CR2: 2b2aca5670a8 CR3: 2d5ef000 CR4:
06e0
Jul 6 14:17:48 valisk kernel: Process insmod (pid: 3557, threadinfo
81002da5, task 810037c54100)
Jul 6 14:17:48 valisk kernel: Stack: 8100381d8bc0 883a7dcf
0008 8186
Jul 6 14:17:48 valisk kernel: 81002da35000 0018a416
810037c542e8 8100381d8be0
Jul 6 14:17:48 valisk kernel: ff01
0012 81002da35000
Jul 6 14:17:48 valisk kernel: Call Trace:
Jul 6 14:17:48 valisk kernel: [883a7dcf]
:usbcore:usb_control_msg+0x8b/0x101
Jul 6 14:17:48 valisk kernel: [883a8736]
:usbcore:usb_get_descriptor+0x72/0xa1
Jul 6 14:17:48 valisk kernel: [883a8d39]
:usbcore:usb_get_device_descriptor+0x4e/0x78
Jul 6 14:17:48 valisk kernel: [883a680c]
:usbcore:usb_add_hcd+0x41c/0x53d
Jul 6 14:17:48 valisk kernel: [883b0044]
:usbcore:usb_hcd_pci_probe+0x1e6/0x28e
Jul 6 14:17:48 valisk kernel: [8032230d] pci_device_probe+0xe2/0x14e
Jul 6 14:17:48 valisk kernel: [8037e546]
driver_probe_device+0xf7/0x174
Jul 6 14:17:48 valisk kernel: [8037e6d9] __driver_attach+0x6f/0xae
Jul 6 14:17:48 valisk kernel: [8037e66a] __driver_attach+0x0/0xae
Jul 6 14:17:48 valisk kernel: [8037e66a] __driver_attach+0x0/0xae
Jul 6 14:17:48 valisk kernel: [8037d962] bus_for_each_dev+0x43/0x6e
Jul 6 14:17:48 valisk kernel: [8037dc88] bus_add_driver+0x7b/0x19d
Jul 6 14:17:48 valisk kernel: [803224eb]
__pci_register_driver+0x58/0x8a
Jul 6 14:17:48 valisk kernel: [8024d854]
sys_init_module+0x1630/0x1793
Jul 6 14:17:48 valisk kernel: [8025cf9b]
audit_syscall_entry+0x141/0x174
Jul 6 14:17:48 valisk kernel: [80209cec] tracesys+0xdc/0xe1
Jul 6 14:17:48 valisk kernel:
Jul 6 14:17:48 valisk kernel:
Jul 6 14:17:48 valisk kernel: Code: 0f 0b eb fe 48 8b 40 08 48 85 c0 75 04 0f
0b eb fe 48 8b 78
Jul 6 14:17:48 valisk kernel: RIP [883a761f]
:usbcore:usb_alloc_urb+0x16/0x9f
Jul 6 14:17:48 valisk kernel: RSP 81002da51bc8
diff -urp vanilla/drivers/usb/class/cdc-acm.c isotree/drivers/usb/class/cdc-acm.c
--- vanilla/drivers/usb/class/cdc-acm.c 2007-07-04 14:14:45.0 +0200
+++ isotree/drivers/usb/class/cdc-acm.c 2007-07-05 13:23:20.0 +0200
@@ -989,7 +989,7 @@ skip_normal_probe:
goto alloc_fail4;
}
- acm-ctrlurb = usb_alloc_urb(0, GFP_KERNEL);
+ acm-ctrlurb = usb_alloc_urb(usb_dev-ep_in[epctrl-bEndpointAddress], ctrlsize, GFP_KERNEL);
if (!acm-ctrlurb) {
dev_dbg(intf-dev, out of memory (ctrlurb
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
Am Donnerstag, 5. Juli 2007 schrieb Matthew Dharm: On Mon, Jul 02, 2007 at 09:15:03AM +0200, Oliver Neukum wrote: Am Montag, 2. Juli 2007 schrieb Alan Stern: If you look at usbmon logs of real usb-storage data transfers you'll see that multi-page sg elements occur quite frequently. (Of course, that doesn't prevent us from transferring only one page per URB.) OK, but the storage driver allocates the URBs on the fly. If we change that to preallocation we need to have enough URBs for the worst case. Of course, in the storage case we control the worst-case. By adjusting the parameter which controls how long a sg list the SCSI core will send us, we can effectively limit the worst-case number of URBs needed. Yes, we can. 1. How high is the price? 2. Is it worth it? 3. Isn't a version using one backup URB better? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] correspondence of gadget and host allocation API
Hi, as you proposed that the APIs of host and gadget be made more similar, I've got questions on the gadget API. struct usb_request *(*alloc_request) (struct usb_ep *ep, gfp_t gfp_flags); void (*free_request) (struct usb_ep *ep, struct usb_request *req); Why is ep passed to free_request() ? Indeed it is not stored in struct usb_request. Is there some subtle reason? alloc_request() is not given the length. Is that because buffers don't matter for preallocation on the gadget side? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch]Fwd: [patch] cdc-acm: add new device id to option driver
USB: add new device id to option driver
device is Samsung X180 China cellphone
Signed-off-by: Andrey Arapov [EMAIL PROTECTED]
Acked-by: Oliver Neukum [EMAIL PROTECTED]
--- linux-2.6.21.i686.orig/drivers/usb/class/cdc-acm.c 2007-04-26 14:08:32.0 +1100
+++ linux-2.6.21.i686/drivers/usb/class/cdc-acm.c 2007-07-04 12:03:48.0 +1100
@@ -1087,6 +1087,9 @@
{ USB_DEVICE(0x0870, 0x0001), /* Metricom GS Modem */
.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
},
+ { USB_DEVICE(0x0e8d, 0x0003), /* FIREFLY, MediaTek Inc; [EMAIL PROTECTED] */
+ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */
+ },
{ USB_DEVICE(0x0482, 0x0203), /* KYOCERA AH-K3001V */
.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
},
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] remove iso frames from standard URB
Am Mittwoch, 4. Juli 2007 schrieb Alan Stern: On Wed, 4 Jul 2007, Oliver Neukum wrote: Hi, as requested, here's a patch that moves the iso frames into their own allocation. That's a prerequisite to most modifications of the API currently being discussed. The name has been changed to something neutral. Seems okay to me. You might also want to change the name of your new local variable in usb_alloc_urb to packets instead of frames. Now the next step will be to remove the iso_packets argument from usb_alloc_urb entirely. We could add a new routine: usb_alloc_iso_urb. Yes. Either my intentions are obvious or you have installed a camera in here. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
Am Montag, 2. Juli 2007 schrieb Alan Stern: On Mon, 2 Jul 2007, Oliver Neukum wrote: The number of interrupts is orthogonal to the question of whether HCD resources are bound to endpoints or to URBs. But if resources are bound to an endpoint the HCD must generate an interrupt when the resources are no longer in use so they can be reused. The HCD has to generate an interrupt anyway when all the queued URBs complete. Drivers simply have to make sure not to submit more URBs than the preallocated resources will support. That's true no matter what the resources are associated with. So the least possible number of interrupts is achieved if all URBs necessary for a transfer are submitted in one go, which means resources for all of them must be available. If we do a full preallocation for the worst case, one code path will do. What if the full preallocation fails but a partial allocation would succeed? A preallocation is done with GFP_KERNEL and not on a block io path, so this is much less of a problem. Probing the device would fail. Furthermore, I am afraid of giving all remaining memory to URBs and not leaving enough for allocation private to the HCDs. That's an argument for preallocating fewer URBs, not more. Why? What is preallocated is already available. The question arises with dynamic allocations. It's a general question. We have to allocate both URBs and HCD-private stuff. It can be done beforehand or dynamically. Either way, if too much memory is spent on URBs there might not be enough for the HCD-private things. The way to avoid the problem is to allocate fewer URBs. Or to allocate private stuff with the URBs. The advantage of preallocation, as Dave pointed out, is that it can be done in process context and hence can use GFP_KERNEL. And that any URB which is allocated can be submitted without caring about memory pressure. Why? Or rather if the amount is determined according to the current granularity or the granularity in the worst case, you associate with the URBs. If you allocate less then you cannot associate with the URBs as you don't have enough resources. We don't want to do both! I agree. These are the choices. I just don't understand which of them you advocate. I give up. It probably won't make much difference in the end. Please don't. This might be an important point and we might not have a disagreement but rather a misunderstanding. Yes, indeed I am not sure that preallocation is the way to go for the storage driver. I care more about cdc-acm, the serial and the video drivers. I thought you were inspired by the problems Pete dsecribed, where mass storage transfers failed because of memory pressure? Yes, I want the storage driver to be reliable. For that one reserve URB will do, provided that usb_submit_urb() never returns -ENOMEM. Matthew wanted to know whether a full preallocation is also possible. I am not sure. For example, let's say you decide to preallocate resources for a mass storage device during usb-storage's probe routine. You don't know how big the transfers will end up being, so you preallocate enough for 120 KB. But the user increases max_sectors and you are faced with a 200-KB transfer. What will you do? Obviously the capabilities advertised to the SCSI layer would need to be limited. I am not sure that this is a good idea. It isn't. We have tried hard to avoid limiting the capabilities unnecessarily. Yes, that's why this is problematic. I see two solutions both with advantages and disadvantages and cannot decide which is better. I was hoping you'd come up with a third solution. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] NIKON D50 problem
Am Dienstag, 3. Juli 2007 schrieb Andrew Morton: Some time ago(I really can't remember version of the kernel) everything was Ok. I'll try to find out the workable version of the kernel ... but I've already tried 2.6.20 - the same =(. I'm not sure, but It's possible that I've had ATA subsystem but not libata ... I haven't tested this case yet. PS. I can see photos on my camera ... flash card is Ok. I have this problem even if I changed the flash card in this camera. It's more likely a usb-storage or scsi layer problem. The device reports as having 1984001 sectors and the kernel is reporting IO errors around the very end of the device. Presumably an IO is straddling end-of-device and we're not handling that correctly. Now I remember. We recently had a report about a buggy device, that close to the end of the medium could handle only requests for single sectors. I'll look into the archive. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] [resend] IRTOUCHSYSTEMS support for usbtouchscreen
Am Montag, 2. Juli 2007 schrieb Ondrej Zary:
+ * IRTOUCH Part
+ */
+#ifdef CONFIG_TOUCHSCREEN_USB_IRTOUCH
+static int irtouch_read_data(struct usbtouch_usb *dev, unsigned char *pkt)
+{
+ dev-x = (pkt[3] 8) | pkt[2];
+ dev-y = (pkt[5] 8) | pkt[4];
+ dev-touch = (pkt[1] 0x03) ? 1 : 0;
+
+ return 1;
+}
+#endif
+
Your description says the higher order byte comes first.
And could you use le16_to_cpu() rsp. be16_to_cpu() to read the values?
It is easier to read.
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 3/4] usb: allocated usb releated dma buffer with kmalloc_node
Am Dienstag, 3. Juli 2007 schrieb Greg KH: On Mon, Jul 02, 2007 at 10:33:12PM -0700, Yinghai Lu wrote: On 7/2/07, Greg KH [EMAIL PROTECTED] wrote: On Mon, Jul 02, 2007 at 03:36:37PM -0700, Yinghai Lu wrote: [PATCH 3/4] usb: allocated usb releated dma buffer with kmalloc_node For amd64 based two way system. USB always on node0. but dma buffer for urb allocated via kmalloc always get ram on node1. So change to kmalloc_node to get dma_buffer on corresponding node Are all of these changes really necessary? You are doing this for some allocations that take a _long_ time when sending to the device due to the speed of the device. I could possibly see this making a difference on some drivers, but for the core, and for the basic USB structures, I can't imagine it is really worth it. Or do you have numbers showing the differences here? Patch included fully below for the benifit of the usb list, which you should have cc:ed... dma buffer could be allocated via alloc_pages_coherent. or kmalloc/dma_map_single. alloc_pages_coherent get the dma_buffer on corresponding node. but kmalloc/dma_map_single always get dma_buffer on last node. or say device is on HT chain node0, it will get dma buffer on node 7 of 8 socket system. also on two way system with 4G+4G RAM conf. device on node 0 will get dma_buffer above 4G, and if the dma_mask is less 32bit, will need extra iommu mapping. In my mcp55+io55 system, it show dma_map_single is keepping called by usb input: keyboard/mouse (8/0x40 bytes), and forcedeth. (0x670bytes) Ok, so two drivers might need this, but not the whole usb core, right? If those two drivers need the extended allocator, why not use it where it is beneficial, even if the benefit is small? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] NIKON D50 problem
It's more likely a usb-storage or scsi layer problem. The device reports as having 1984001 sectors and the kernel is reporting IO errors around the very end of the device. Presumably an IO is straddling end-of-device and we're not handling that correctly. Can you try the work around suggested here: https://lists.one-eyed-alien.net/pipermail/usb-storage/2007-June/003053.html Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 3/4] usb: allocated usb releated dma buffer with?kmalloc_node
Am Dienstag, 3. Juli 2007 schrieb Greg KH: Ok, so two drivers might need this, but not the whole usb core, right? If those two drivers need the extended allocator, why not use it where it is beneficial, even if the benefit is small? What is the benefit? Speed isn't an issue here, so what is? Speed is always an issue. Every cycle used in the kernel is lost to user space. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB mouse autosuspend
Am Dienstag, 3. Juli 2007 schrieb Jiri Kosina: OK, it seems that vendors of usb keyboards probably rely too much on fact that the keyboards could be quite slow and flaky without anyone complaining under normal load, and therefore implement the things very badly. Oliver, I currently think that usb hid autosuspend would bring much more problems than it would give us. I see the problems. Is there a way we can get the CPU into C2 while we have HID running? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] for NIKON D50 as UMS
Am Dienstag, 3. Juli 2007 schrieb S.Çağlar Onur: Hmm i have NIKON D50 also and it works here without a problem with Linus's current git. Please provide the full lsusb -v for your devices, both of you. You might have different versions of the device. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch/rfc 2.6.22-rc7] usb/dma doc updates
Am Montag, 2. Juli 2007 schrieb David Brownell: + Most drivers should *NOT* be using these primitives. On most systems + the memory returned will be uncached, so it's a bit more expensive to + access than what kmalloc() returns. This is somewhat hard to understand. If we use this memory as a real working space it makes sense. But if we do a memcpy() into the buffer, why do we care? The data has to hit RAM for DMA to work. So why not do the work at once, at least in the write path? We are as an advantage sure to get memory we can do DMA to. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
Am Montag, 2. Juli 2007 schrieb Alan Stern: On Sun, 1 Jul 2007, Oliver Neukum wrote: It happens when the URB is destroyed. I'm not convinced that it's a good idea to couple allocations and deallocation to URBs like this. They could be handled separately from URBs. Yes, but what for? The earliest possible time is when the URB is allocated, the latest time is at usb_submit_urb(). Anything in between requires a further function call. Notice also that the usb-storage doesn't reuse URBs for its large data transfers (ub might work differently; I don't know). Those are all done using one-shot URBs allocated by the scatter-gather library. Do you intend to change how that works? That is a long term goal and would require some invasive changes in the storage driver. It shouldn't require changes to usb-storage, only changes to the s-g library. Yes, though the sg api would probably need to change. Another thing worth noticing is that with reusable URBs, at allocation time you might not know the transfer lengths you will need. Drivers would have to guess at the maximum requirement and then live with that guess. I doubt this is a common problem. Only rarely will a driver transfer more than PAGE_SIZE. If you look at usbmon logs of real usb-storage data transfers you'll see that multi-page sg elements occur quite frequently. (Of course, that doesn't prevent us from transferring only one page per URB.) OK, but the storage driver allocates the URBs on the fly. If we change that to preallocation we need to have enough URBs for the worst case. Finally, don't forget the advantages of avoiding preallocation and keeping resources in a pool, available for multiple uses. What are these, beyond memory usage? There aren't any others, clearly. But memory usage is enough. My goals are: - speed up things for drivers that maintain pools of URBs: some serial drivers, cdc-acm, video drivers ... Your work would have the opposite effect! By tying URBs to specific endpoints, you would force these drivers to stop using URB pools. (Although that might not be a bad thing in the long run...) Or maybe the drivers would dedicate a pool for each individual device, instead of allowing all devices to use URBs from a common pool. So okay, for streaming or almost-streaming transfers you would speed things up by avoiding the constant allocation and deallocation. cdc-acm already does use one pool per device. Which drivers work otherwise? They will scale badly for multiple devices. Common pools are a bad idea. Furthermore every driver that does a resubmission in interrupt profits. We have something of a blind spot here. Driving a device at hardware speeds is not very good if it sucks up too many cpu cycles. I still think it might be better to do this at the level of endpoints rather than individual URBs. Keep in mind that this is how our current USB stack is oriented: towards endpoint queues, not single URBs. Unlike the previous stack. Please elaborate. I thought that by linking URBs to endpoints, I'd orient the stack towards endpoints, not individual URBs. - reduce CPU usage in interrupt handlers and in general - remove some nasty ENOMEM error cases - guarantee the storage driver a fallback path without memory allocation Worthy goals. But is this the best way to accomplish them? Avoiding memory allocations is the simplest way to avoid ENOMEM for sure. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Bugme-new] [Bug 8564] New: ftdi_sio: BUG: unable to handle kernel NULL pointer dereference at virtual address
Am Samstag, 30. Juni 2007 schrieb Gene Heskett: Sorry Oliver, no use trying even, the search strings here are indented, usually 2 spaces, those in the kernels since at least 2.6.21.1, the oldest src I still have, are not. I just tried this patch with 2.6.22-rc6. It applied flawlessly. What .rejects do you get? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch/rfc 2.6.22-rc7] usb/dma doc updates
Am Montag, 2. Juli 2007 schrieb David Brownell: On Monday 02 July 2007, Oliver Neukum wrote: Am Montag, 2. Juli 2007 schrieb David Brownell: + Most drivers should *NOT* be using these primitives. On most systems + the memory returned will be uncached, so it's a bit more expensive to + access than what kmalloc() returns. This is somewhat hard to understand. Should that be two separate paragraphs then? don't, then this is probably going to be uncached. ? Yes. In addition it needs to be more explicit. And perhaps a bit about how to treat uncached memory. If we use this memory as a real working space it makes sense. But if we do a memcpy() into the buffer, why do we care? The data has to hit RAM for DMA to work. So why not do the work at once, at least in the write path? We are as an advantage sure to get memory we can do DMA to. The reason not to use those operations is that most drivers have no need for dma-coherent memory. The normal stuff does just fine. Then you need to write exactly that. It is not stated as such. And please explain why we can operate efficiently with kmalloced memory although we don't evaluate the controller's dma mask. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
Am Montag, 2. Juli 2007 schrieb David Brownell: On Saturday 30 June 2007, Oliver Neukum wrote: --- linux-2.6.22rc6vanilla/include/linux/usb.h +++ linux-2.6.22-rc6-iso/include/linux/usb.h @@ -1152,7 +1152,7 @@ struct urb int error_count;/* (return) number of ISO errors */ void *context; /* (in) context for completion */ usb_complete_t complete;/* (in) completion routine */ - struct usb_iso_packet_descriptor iso_frame_desc[0]; + struct usb_iso_packet_descriptor *iso_frames; If you're going to make this change, please remove the fullspeed-centricity of those names. Although to be fair, even at full speed the use of frame was incorrect ... the period could be any number of frames. For high speed of course the periods are measured in microframes. I suggest calling the field iso_packets instead. I'll do so. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
Am Montag, 2. Juli 2007 schrieb David Brownell: Since each sg element refers to a page or more of data, the maximum number of elements is restricted by the maximum allowed transfer size (which is currently 512 KB or 128 pages on i386). The default max transfer size set by usb-storage is 120 KB. Larger values would lead to larger throughput but the benefit would be slight. The relevant factor their being per-request overhead: usb-storage must send a command, transfer data, get a response; and scatterlist code only improves the transfer data bits. That is, it can get rid of wasted bus time between data packets ... but not wasted time surrounding the command or response. But if we curtail the list, we will need more overhead per payload, as the payload transfered by each transfer gets smaller. However none of this matters if you don't insist on allocating a separate URB for each sg element. As noted above, for full speed devices we could get similar throughput with slightly more clever implementation of scatterlist handling. If the HCD has good hardware support for queueing, and the system has fair IRQ latency, recycling as few as five URBs might give similar throughput to the current URB per element approach. I don't like the idea of the sg code differentiating between the HCDs. BTW, it seems to me that the current sg code is underutilizing the sg capability inherent in EHCI's qtds. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocation s to usb_alloc_urb ()
Am Montag, 2. Juli 2007 schrieb David Brownell:
On Saturday 30 June 2007, Oliver Neukum wrote:
So do we have consensus for this prototype:
struct urb *usb_alloc_urb(struct usb_host_endpoint *ep,
unsigned int max_length, unsigned int iso_fields,
gfp_t mem_flags);
Calling conventions that require line-wrapping are almost by
definition unwieldy ... :(
In usbcore we have names_containing_exact_descriptions.
But yes. I intended to find a unified API that allows preallocation.
If we can live with a separate allocator for ISO URBs, we can
do better.
That might make sense for an HCD method; size_t for length,
and rename it so it doesn't suggest it's a maximum so much
as an educated guess.
So you are suggesting that usbcore should preallocate, but
also, if need be allocate more in usb_submit_urb()? So that
the guarantee against getting ENOMEM is valid only if you
don't exceed the hint given at allocation time?
That is an idea I would have never had, but it is very good.
But otherwise, I thought one of the goals was to get rid of
such annoying iso fields (should be packets, not fields!)
parameters, which were always being passed as zero ... ?
I'd expect drivers would just pass {ep, length, gfp} except
for the rare ISO ones, which would pass the number of packets.
That suggests two separate signatures at that level.
OK.
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch]fix for ftdi_sio quirk handling
Hi,
this one fixes an oops with quirky ftdi_sio devices. As it fixes a
regression, I propose that it be included in 2.6.22
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
---
--- linux-2.6.22-rc3/drivers/usb/serial/ftdi_sio.c.alt 2007-06-04
10:38:45.0 +0200
+++ linux-2.6.22-rc3/drivers/usb/serial/ftdi_sio.c 2007-06-04
11:06:27.0 +0200
@@ -271,26 +271,58 @@ static int debug;
static __u16 vendor = FTDI_VID;
static __u16 product;
+struct ftdi_private {
+ ftdi_chip_type_t chip_type;
+ /* type of the device, either SIO or FT8U232AM
*/
+ int baud_base; /* baud base clock for divisor setting */
+ int custom_divisor; /* custom_divisor kludge, this is for baud_base
(different from what goes to the chip!) */
+ __u16 last_set_data_urb_value ;
+ /* the last data state set - needed for doing a
break */
+int write_offset; /* This is the offset in the usb data block to
write the serial data -
+* it is different between devices
+*/
+ int flags; /* some ASYNC_ flags are supported */
+ unsigned long last_dtr_rts; /* saved modem control outputs */
+wait_queue_head_t delta_msr_wait; /* Used for TIOCMIWAIT */
+ char prev_status, diff_status;/* Used for TIOCMIWAIT */
+ __u8 rx_flags; /* receive state flags (throttling) */
+ spinlock_t rx_lock; /* spinlock for receive state */
+ struct delayed_work rx_work;
+ struct usb_serial_port *port;
+ int rx_processed;
+ unsigned long rx_bytes;
+
+ __u16 interface;/* FT2232C port interface (0 for FT232/245) */
+
+ int force_baud; /* if non-zero, force the baud rate to this
value */
+ int force_rtscts; /* if non-zero, force RTS-CTS to always be
enabled */
+
+ spinlock_t tx_lock; /* spinlock for transmit state */
+ unsigned long tx_bytes;
+ unsigned long tx_outstanding_bytes;
+ unsigned long tx_outstanding_urbs;
+};
+
/* struct ftdi_sio_quirk is used by devices requiring special attention. */
struct ftdi_sio_quirk {
int (*probe)(struct usb_serial *);
- void (*setup)(struct usb_serial *); /* Special settings during startup.
*/
+ void (*port_probe)(struct ftdi_private *); /* Special settings for
probed ports. */
};
static int ftdi_olimex_probe (struct usb_serial *serial);
-static void ftdi_USB_UIRT_setup (struct usb_serial *serial);
-static void ftdi_HE_TIRA1_setup (struct usb_serial *serial);
+static void ftdi_USB_UIRT_setup (struct ftdi_private *priv);
+static void ftdi_HE_TIRA1_setup (struct ftdi_private *priv);
static struct ftdi_sio_quirk ftdi_olimex_quirk = {
.probe = ftdi_olimex_probe,
};
static struct ftdi_sio_quirk ftdi_USB_UIRT_quirk = {
- .setup = ftdi_USB_UIRT_setup,
+ .port_probe = ftdi_USB_UIRT_setup,
};
static struct ftdi_sio_quirk ftdi_HE_TIRA1_quirk = {
- .setup = ftdi_HE_TIRA1_setup,
+ .port_probe = ftdi_HE_TIRA1_setup,
};
/*
@@ -566,38 +598,6 @@ static const char *ftdi_chip_name[] = {
#define THROTTLED 0x01
#define ACTUALLY_THROTTLED 0x02
-struct ftdi_private {
- ftdi_chip_type_t chip_type;
- /* type of the device, either SIO or FT8U232AM
*/
- int baud_base; /* baud base clock for divisor setting */
- int custom_divisor; /* custom_divisor kludge, this is for baud_base
(different from what goes to the chip!) */
- __u16 last_set_data_urb_value ;
- /* the last data state set - needed for doing a
break */
-int write_offset; /* This is the offset in the usb data block to
write the serial data -
-* it is different between devices
-*/
- int flags; /* some ASYNC_ flags are supported */
- unsigned long last_dtr_rts; /* saved modem control outputs */
-wait_queue_head_t delta_msr_wait; /* Used for TIOCMIWAIT */
- char prev_status, diff_status;/* Used for TIOCMIWAIT */
- __u8 rx_flags; /* receive state flags (throttling) */
- spinlock_t rx_lock; /* spinlock for receive state */
- struct delayed_work rx_work;
- struct usb_serial_port *port;
- int rx_processed;
- unsigned long rx_bytes;
-
- __u16 interface;/* FT2232C port interface (0 for FT232/245) */
-
- int force_baud; /* if non-zero, force the baud rate to this
value */
- int force_rtscts; /* if non-zero, force RTS-CTS to always be
enabled */
-
- spinlock_t tx_lock; /* spinlock for transmit state */
- unsigned long tx_bytes;
- unsigned long
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb ()
Am Montag, 2. Juli 2007 schrieb Hans Petter Selasky: Hi Oliver! What you're trying to do is what the HPS USB stack for FreeBSD has been doing for a while. See for example: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ohci.c Look at the function: static usbd_status ohci_xfer_setup(struct usbd_device *udev, u_int8_t iface_index, struct usbd_xfer **pxfer, const struct usbd_config *setup_start, const struct usbd_config *setup_end) Maybe you want to take your approach one step further and allow allocation of multiple URB structures in the same go ? This API looks too complicated for my taste. This looks like sg support is native to BSD's version of an URB. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
Am Montag, 2. Juli 2007 schrieb Alan Stern: As noted above, for full speed devices we could get similar throughput with slightly more clever implementation of scatterlist handling. If the HCD has good hardware support for queueing, and the system has fair IRQ latency, recycling as few as five URBs might give similar throughput to the current URB per element approach. I think we definitely should do this. For high speed the advantages aren't so great, since the amount of data needed to fill the pipeline is about the same as the default max transfer size anyway. Doesn't this boil down to using CPU cycles to save memory? Even worse, many of these cycles would be used in interrupt context. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Bugme-new] [Bug 8698] New: linux kernel usb-serial problem
Am Montag, 2. Juli 2007 schrieb Andrew Morton:
On Sun, 1 Jul 2007 13:50:23 -0700 (PDT) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8698
Summary: linux kernel usb-serial problem
Product: Other
Version: 2.5
KernelVersion: 2.6.21-5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Most recent kernel where this bug did not occur: unknown
Distribution: fedora 7
Hardware Environment: dell dimension 2300
Software Environment: fedora 7 gnome
Problem Description: lirc serial device home electronics tira-2 causes an
oops
in the kernel. tried w/fedora 7 stock kenernel 2.6.21-1 and vanilla kernel
2.6.21-5 w/same problem. tried w/o lirc installed and configured, same
problem.problem may be w/ftd_sio module but does not appear to be.
output
of dmesg:
The output seems incomplete. Try the attached patch. If it does not help,
recompile with CONFIG_USB_DEBUG and provide the full log.
Regards
Oliver
--- linux-2.6.22-rc3/drivers/usb/serial/ftdi_sio.c.alt 2007-06-04 10:38:45.0 +0200
+++ linux-2.6.22-rc3/drivers/usb/serial/ftdi_sio.c 2007-06-04 11:06:27.0 +0200
@@ -271,26 +271,58 @@ static int debug;
static __u16 vendor = FTDI_VID;
static __u16 product;
+struct ftdi_private {
+ ftdi_chip_type_t chip_type;
+/* type of the device, either SIO or FT8U232AM */
+ int baud_base; /* baud base clock for divisor setting */
+ int custom_divisor; /* custom_divisor kludge, this is for baud_base (different from what goes to the chip!) */
+ __u16 last_set_data_urb_value ;
+/* the last data state set - needed for doing a break */
+int write_offset; /* This is the offset in the usb data block to write the serial data -
+ * it is different between devices
+ */
+ int flags; /* some ASYNC_ flags are supported */
+ unsigned long last_dtr_rts; /* saved modem control outputs */
+wait_queue_head_t delta_msr_wait; /* Used for TIOCMIWAIT */
+ char prev_status, diff_status;/* Used for TIOCMIWAIT */
+ __u8 rx_flags; /* receive state flags (throttling) */
+ spinlock_t rx_lock; /* spinlock for receive state */
+ struct delayed_work rx_work;
+ struct usb_serial_port *port;
+ int rx_processed;
+ unsigned long rx_bytes;
+
+ __u16 interface; /* FT2232C port interface (0 for FT232/245) */
+
+ int force_baud; /* if non-zero, force the baud rate to this value */
+ int force_rtscts; /* if non-zero, force RTS-CTS to always be enabled */
+
+ spinlock_t tx_lock; /* spinlock for transmit state */
+ unsigned long tx_bytes;
+ unsigned long tx_outstanding_bytes;
+ unsigned long tx_outstanding_urbs;
+};
+
/* struct ftdi_sio_quirk is used by devices requiring special attention. */
struct ftdi_sio_quirk {
int (*probe)(struct usb_serial *);
- void (*setup)(struct usb_serial *); /* Special settings during startup. */
+ void (*port_probe)(struct ftdi_private *); /* Special settings for probed ports. */
};
static int ftdi_olimex_probe (struct usb_serial *serial);
-static void ftdi_USB_UIRT_setup (struct usb_serial *serial);
-static void ftdi_HE_TIRA1_setup (struct usb_serial *serial);
+static void ftdi_USB_UIRT_setup (struct ftdi_private *priv);
+static void ftdi_HE_TIRA1_setup (struct ftdi_private *priv);
static struct ftdi_sio_quirk ftdi_olimex_quirk = {
.probe = ftdi_olimex_probe,
};
static struct ftdi_sio_quirk ftdi_USB_UIRT_quirk = {
- .setup = ftdi_USB_UIRT_setup,
+ .port_probe = ftdi_USB_UIRT_setup,
};
static struct ftdi_sio_quirk ftdi_HE_TIRA1_quirk = {
- .setup = ftdi_HE_TIRA1_setup,
+ .port_probe = ftdi_HE_TIRA1_setup,
};
/*
@@ -566,38 +598,6 @@ static const char *ftdi_chip_name[] = {
#define THROTTLED 0x01
#define ACTUALLY_THROTTLED 0x02
-struct ftdi_private {
- ftdi_chip_type_t chip_type;
-/* type of the device, either SIO or FT8U232AM */
- int baud_base; /* baud base clock for divisor setting */
- int custom_divisor; /* custom_divisor kludge, this is for baud_base (different from what goes to the chip!) */
- __u16 last_set_data_urb_value ;
-/* the last data state set - needed for doing a break */
-int write_offset; /* This is the offset in the usb data block to write the serial data -
- * it is different between devices
- */
- int flags; /* some ASYNC_ flags are supported */
- unsigned long last_dtr_rts; /* saved modem control outputs */
-wait_queue_head_t delta_msr_wait; /* Used for TIOCMIWAIT */
- char prev_status, diff_status;/* Used for TIOCMIWAIT */
- __u8 rx_flags; /* receive state flags (throttling) */
- spinlock_t rx_lock; /* spinlock for receive state */
- struct delayed_work rx_work;
- struct usb_serial_port *port;
- int rx_processed;
-
Re: [linux-usb-devel] patch to shift memory allocations to usb_alloc_urb()
Am Montag, 2. Juli 2007 schrieb Alan Stern: On Mon, 2 Jul 2007, Oliver Neukum wrote: Am Montag, 2. Juli 2007 schrieb Alan Stern: On Sun, 1 Jul 2007, Oliver Neukum wrote: It happens when the URB is destroyed. I'm not convinced that it's a good idea to couple allocations and deallocation to URBs like this. They could be handled separately from URBs. Yes, but what for? The earliest possible time is when the URB is allocated, the latest time is at usb_submit_urb(). Anything in between requires a further function call. Not so. The resources can be _allocated_ arbitrarily early. The earliest possible time they could be _used_ is when an URB is submitted (not when it is allocated!). OK, so the earliest time they can be cleared for use by an URB is when the URB is allocated. The allocation can be at any time before that. Furthermore, if you do things this way then you could share an endpoint's resources among a bunch of URBs. For example, suppose you stream data to an endpoint, using 8 URBs. Doesn't it make sense to allocate sufficient endpoint resources for all 8 in one function call, rather than allocating the resources for each URB along with that URB? Up to a point. Particularly not when it means taking more interrupts. RAM is growing faster than cpu speed. If you look at usbmon logs of real usb-storage data transfers you'll see that multi-page sg elements occur quite frequently. (Of course, that doesn't prevent us from transferring only one page per URB.) OK, but the storage driver allocates the URBs on the fly. If we change that to preallocation we need to have enough URBs for the worst case. (The s-g library allocates those URBs, not usb-storage.) We _don't_ have to preallocate enough URBs for the worst case. At most we should preallocate enough to keep the pipeline filled. In case of bad memory pressure, we can live with preallocating only one URB. It'll be slow, but it's better than failing the I/O. Iff we are willing to have two code paths. Furthermore, I am afraid of giving all remaining memory to URBs and not leaving enough for allocation private to the HCDs. I still think it might be better to do this at the level of endpoints rather than individual URBs. Keep in mind that this is how our current USB stack is oriented: towards endpoint queues, not single URBs. Unlike the previous stack. Please elaborate. I thought that by linking URBs to endpoints, I'd orient the stack towards endpoints, not individual URBs. Only partially. It makes sense to say that you want to preallocate enough storage to transfer 32 KB to an endpoint. It doesn't make as much sense to preallocate 4 KB worth of storage to each of 8 URBs. But the amount of resources needed depends on the granularity. The fact is that bulk endpoints consume an almost uniform stream of data, with only short packets to mark any sort of boundary. The division of that stream into URBs is rather artificial; for bulk streaming it mainly reflects the inability of the HCDs to handle scatterlists. Yes, so an URB describes a part of a stream contiguous to DMA. As this granularity determines the number of tds, qtds ... needed, this seems sensible to me. Of course, it's not a necessity to use URBs, but firstly an asynchronous API will need some kind of handle and secondly I had not envisioned so deep a surgery on usbcore. Besides, there's also the practical aspect. If you force URBs to be linked to endpoints, you will have to audit many drivers. I don't know how many of them will need changes. But adding new function calls for preallocation and release will affect only a few HCDs plus whatever drivers want to use the new calls. Yes, but after that audit there'll be a unified API again. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
