[linux-usb-devel] host controller process error: who done it?
If I try to queue bulk urbs to an endpoint (2.5, uhci-hcd), I rapidly get host controller process error. something bad happened followed by host controller halted. very bad. In order to track down what went wrong, I would like to know which TD caused the host controller to barf, which QH it is in, which urb it is for etc. The problem is that I don't see how to find out which TD is causing the problem. That information does not seem to be retrievable from the host controller. Any suggestions for how to determine (in uhci_irq for example) where things went wrong? Thanks, Duncan. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [patch 2.5.70] kerneldoc for gadget API
On Mon, Jun 02, 2003 at 11:36:03AM -0700, David Brownell wrote: Here's the non-inlined doc for the gadget API. Please merge to Linus' tree. Applied, thanks. greg k-h --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: usb_set_configuration in empeg.c
On Wed, Jun 04, 2003 at 10:59:48AM +0200, Oliver Neukum wrote: Hi, you should not drop errors. Applied, thanks. greg k-h --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: cut usb_set_config from hpusbscsi
On Wed, Jun 04, 2003 at 10:28:11AM +0200, Oliver Neukum wrote: Hi Greg, this cuts out old cruft. Please apply. Applied, thanks. But now there's a compiler warning :) greg k-h --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [BK PATCH] More USB changes for 2.5.70
On Tue, Jun 03, 2003 at 07:23:35PM -0400, Ben Collins wrote: Ben, it looks like your patch broke something for USB keyboards, any idea? Yep, my patch killed hid-input from scanning HID_OUTPUT_REPORT's. Fixed with this patch for 2.5.70+bk. I'll send one for 2.4.x in a few minutes. Applied, thanks. But I cut out this part: @@ -418,8 +421,7 @@ struct input_dev *input = find_input(hid, field); int *quirks = hid-quirks; - if (!input) - return; + BUG_ON(!input); input_regs(input, regs); I don't want to add any BUG_ON() calls to the USB drivers. thanks, greg k-h --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
On Iau, 2003-06-05 at 00:02, [EMAIL PROTECTED] wrote: I did mention in one of the other postings that multiple drivers were not precluded. It would be perfectly valid to register multiple drivers for the same VID/PID combination. This would be the exception, but it would certainly support the situations which you suggested. Yes. One thing that bothers me about some of the discussion is the assumption of one path or the other with solving things. Linux generally takes the approach of allowing the unusual when it makes sense. We have similar issues with certain combo PCI cards (especially parallel-serial combo) and they just have their own driver, because its easier than a giant magical sharing layer in the PCI core --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [BK PATCH] More USB changes for 2.5.70
On Thu, Jun 05, 2003 at 01:20:15AM -0700, Greg KH wrote: On Tue, Jun 03, 2003 at 07:33:52PM -0400, Ben Collins wrote: Greg, if this doesn't apply to your 2.4.x tree, could you please send me an updated tarball of your tree? Applied, minus the BUG_ON() part. Thanks. Do you still want a tarball/patch of my usb 2.4 tree? This patch applied just fine with no fuzz. thanks, Yes, please. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Yet another revision of the ax8817x driver
Greg KH wrote: On Sat, May 31, 2003 at 07:01:56PM -0400, David T Hollis wrote: Here you are. Would be happy to see it included mainline. A few comments. First off, I need a 2.5 version first before I can add it to 2.4 You need to follow the coding style rules found at Documentation/CodingStyle (basically use tabs, and don't use the extra spaces in your if statements: if (foo) not if ( foo ) Same thing for function calls. thanks, greg k-h Sounds good. I've ran the 2.4 driver against indent so he should be good. I'll get a patch to you sometime today on that. The 2.5 port is pretty close to done. Had some issues with the API changes but once I had that figured out, he's working to a certain extent. Just noticed a rather ugly glitch in that when I start an SSH session TO the box running the driver, it bombs out hard with a problem in the tx_callback. I think after I have that part worked out, it will be in pretty good shape. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Pontis SP600 + 2.4.20 = kernel panic
Hi Alan! Yes, you are right, I used kernel 2.4.20. The last days I tried to reproduce the problem with 2.4.21-rc3 but I failed. It 2.4.21-rc3 seems to be fixed in that version. :-) But I have another problem also with 2.4.21-rc3. The data I transmit to the device gets corrupt. If I copy clean, self-build mp3's to the device I listen some CLICK. If I copy programs or other files to the device and try to use them later, they are damaged. PONTIS the vendor confirmed this problem with some configurations of chipset and driver. My question: is it possible to write a workaround in the Linux-USB driver for this problem? Thank you! Joschua Joschua: Although you didn't say what version of the kernel you were running, the log you just sent must have been from 2.4.20. Try sending a log from 2.4.21-rc1 or anything more recent. Jun 2 23:31:34 debian kernel: sdb: test WP failed, assume Write Enabled This message is harmless. Jun 2 23:32:49 debian kernel: usb-storage: Command START_STOP (6 bytes) This message shows the command that crashed your player. Starting in 2.4.21-rc1, Linux no longer uses the START-STOP command, so it should work better with your device. Alan Stern -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] There's no definition of struct usb_ctrlrequest in my kernel-source-2.4.18!
Hi,james Sorry for disturbing you!I send this mail to u as I know from internet that you can help me. I can't find any definition of usb_ctrlrequest in my Linux kernel-source-2. 4.18.I searched in internet,they say it is in usb.h,But I can't find any of the definition. So I wonder if it is removed from the new linux kernel sources? Thanks for your concern! Cloud S.Y Wu --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch/rft 2.5.70] usb_set_configuration()can change configs
Oliver Neukum wrote: Am Donnerstag, 5. Juni 2003 22:16 schrieb David Brownell: In short, usb_set_configuration() now does what it's supposed to do: it changes the device config, and all usbcore state depending on it. Way cool. A few points. 1. We need a special function for devices that just reset the current config. It seems that there are really buggy devices which need this. Yes, something like usb_reset_config(dev) call is needed. As well as converting code to use it, instead of the current calls to usb_set_configuration() in drivers. 2. You can set hubs to config 0. What will that do? You can set anything to config 0 -- perfectly reasonable. I take it you're suggesting that hubs are special enough that allowing that to happen would be a Bad Thing? Makes sense to me. Suggestion? - Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB storage timeout and oops
Alan Stern wrote: David: Jun 5 20:53:25 ventus kernel: usb-storage: Attempting to get CSW... Jun 5 20:53:25 ventus kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jun 5 20:53:55 ventus kernel: usb-storage: usb_storage_command_abort called Jun 5 20:53:55 ventus kernel: usb-storage: usb_stor_stop_transport called Jun 5 20:53:55 ventus kernel: usb-storage: -- cancelling URB Jun 5 20:53:55 ventus kernel: usb-storage: Status code -104; transferred 0/13 Jun 5 20:53:55 ventus kernel: usb-storage: -- transfer cancelled Jun 5 20:53:55 ventus kernel: usb-storage: Bulk status result = 3 Jun 5 20:53:55 ventus kernel: usb-storage: -- command was aborted But the accompanying status bulk-in transfer timed out. Unfortunately, there's no information from the EHCI driver to indicate if anything else happened. Andras, if you notice distinct pauses, and this is on 2.5 (seems to be), then there's more information available. Basically, the sysfs files for EHCI (enabled with CONFIG_USB_DEBUG) may have relevant information. Make sure you're running a kernel with the kernel hacking debug memory allocations option enabled. Then when it pauses, copy the async file for that controller and send it to me. In fact, just make a copy of every file in the relevant sysfs directory (it'll be something like /sys/bus/pci/devices/00:09.2). Then it asked for a hard device reset, which translates into usb_reset_device(). The debugging messages added by Andras, which I've removed here, make it clear that usb_hub_port_wait_reset() eventually returns 1, indicating a disconnect. I tend to believe such reports. Why it went away is a question. I strongly suspect -- but I don't know for certain -- that the device did not really disconnect itself electrically from the bus. In fact, Andras stated that rebooting without unplugging or powering-off the device got everything working again. Rebooting tends to do that, regardless. We know the reset_device() code is problematic; reboot does it right, we know that! Does this suggest any place to start looking in the EHCI driver? Would turning on the driver's verbose debugging help? Is there anything else to try? If it's the kind of failure I half suspect, the async schedule dump will say what's up. - Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb_buffer_alloc flags in probe function
On Wed, 4 Jun 2003, Daniele Bellucci wrote: Hi, i've found some usb_buffer_alloc with GFP_KERNEL on in a probe function (kernel 2.5.70). Since probe isn't ever called in process context... is that correct? You have that exactly backwards. probe() is _always_ called in process context, in fact in the context of the khubd kernel thread. Alan Stern --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: cut config changes from stv680
I'm not sure if this is a good idea. The config routine was adapted from data provided by using the usb snoopy program in Windows, and from the info I got from STM on the STV0680. You have check each step in a certain way when configuring that chip. Greg, please do not apply this patch until I have had a chance to go over the config info from STM again. Kevin Oliver Neukum wrote: Hi, you always set the same configuration. This makes doing so quite pointless. Regards Oliver You can import this changeset into BK by piping this whole message to: '| bk receive [path to repository]' or apply the patch as usual. === [EMAIL PROTECTED], 2003-06-04 10:46:55+02:00, [EMAIL PROTECTED] - cut unneeded config changes snip --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB storage timeout and oops
This is good. And quite interesting. It illustrates a problem with the current SCSI code as well as a problem with the USB drivers. By the way, Andras, was the device plugged directly into your computer's USB port or did you use an intermediate hub? On Tue, 3 Jun 2003, Major A wrote: Jun 3 23:06:27 ventus kernel: usb-storage: Status code 0; transferred 131072/131072 That's the last successful read. Following this we have a sequence of failed DATA-IN and control transfers, with one successful DATA-OUT. Why that should have worked when the others failed is beyond me. snip Jun 3 23:07:17 ventus kernel: usb-storage: Command TEST_UNIT_READY (6 bytes) Jun 3 23:07:17 ventus kernel: usb-storage: 00 00 00 00 00 00 Jun 3 23:07:17 ventus kernel: usb-storage: Bulk command S 0x43425355 T 0x129 Trg 0 LUN 0 L 0 F 0 CL 6 Jun 3 23:07:17 ventus kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jun 3 23:07:17 ventus kernel: usb-storage: Status code 0; transferred 31/31 Jun 3 23:07:17 ventus kernel: usb-storage: -- transfer complete Jun 3 23:07:17 ventus kernel: usb-storage: Bulk command transfer result=0 That's the successful DATA-OUT. snip Jun 3 23:08:07 ventus kernel: usb-storage: usb_storage_bus_reset called Jun 3 23:08:07 ventus kernel: hub 5-2:0: port 2 not reset yet, waiting 10ms Jun 3 23:08:07 ventus kernel: usb-storage: usb_reset_device returns -19 ENODEV from a port reset? Sounds like a problem with the root hub driver or the controller itself. Or else the device crashed _really_ hard. Jun 3 23:08:07 ventus kernel: scsi: Device offlined - not ready after error recovery: host 2 channel 0 id 0 lun 0 Jun 3 23:08:07 ventus kernel: SCSI disk error : 2 0 0 0 return code = 0x605 Jun 3 23:08:07 ventus kernel: end_request: I/O error, dev sda, sector 47975616 Here the SCSI layer gave up on the device and set it offline. All the I/O requests from this point will fail. Jun 3 23:08:07 ventus kernel: usb-storage: queuecommand() called Jun 3 23:08:07 ventus kernel: Buffer I/O error on device sda1, logical block 5996948 Jun 3 23:08:07 ventus kernel: usb-storage: *** thread awakened. Jun 3 23:08:07 ventus kernel: usb-storage: Command WRITE_10 (10 bytes) But oddly enough, even though the device is off-line the SCSI driver has queued another WRITE command. That shouldn't have happened, and of course it fails. Anything after this is just reiserfs complaining. What I did, BTW, is to boot the computer, mount the external drive, during which reiserfs checks the transaction log (which in this case was non-empty, so it definitely wrote data to the disk), then after a few directory listings I do an md5sum *.png md5sums in one of the directories on the disk, and this pretty instantly causes the abovementioned timeout/oops/whatever. Hope this helps a bit. If you need more info, please let me know what I have to do in order to get it as I'm not really familiar with the debug options. Alan Stern --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB storage timeout and oops
By the way, Andras, was the device plugged directly into your computer's USB port or did you use an intermediate hub? It was plugged into a USB 2.0 hub, but behaviour is exactly the same when it's plugged in directly (well, maybe there is less stuff in the logs, I haven't tried). Let me know if you want me to try that as well. ENODEV from a port reset? Sounds like a problem with the root hub driver or the controller itself. Or else the device crashed _really_ hard. Don't think it crashed -- it is self-powered, and if I reboot the computer, it works again although it hasn't been powered down at any time. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] HTTP
http://www.cnxp.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] PATCH: Don't allocate transfer buffers on the stack in hub.c
On Tue, 3 Jun 2003, Greg KH wrote:
On Tue, Jun 03, 2003 at 04:59:31PM -0400, Alan Stern wrote:
I've been told it's not a good idea to put transfer buffers on the stack,
as that's not DMA-able on some architectures. Nevertheless, it's done in
the USB core (well, I found one place in hub.c that does it -- but that's
after only 1 minute of looking).
Does this need to be cleaned up?
Yes. I thought we had fixed all of this in the past, did we miss
something?
This should fix things. I added buffer space (4 bytes) in struct usb_hub
to store the status reports.
Alan Stern
= hub.c 1.105 vs edited =
--- 1.105/drivers/usb/core/hub.cSat May 24 18:40:11 2003
+++ edited/drivers/usb/core/hub.c Wed Jun 4 11:32:10 2003
@@ -103,21 +103,23 @@
/*
* USB 2.0 spec Section 11.24.2.6
*/
-static int usb_get_hub_status(struct usb_device *dev, void *data)
+static int usb_get_hub_status(struct usb_device *dev,
+ struct usb_hub_status *data)
{
return usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_HUB, 0, 0,
- data, sizeof(struct usb_hub_status), HZ);
+ data, sizeof(*data), HZ);
}
/*
* USB 2.0 spec Section 11.24.2.7
*/
-static int usb_get_port_status(struct usb_device *dev, int port, void *data)
+static int usb_get_port_status(struct usb_device *dev, int port,
+ struct usb_port_status *data)
{
return usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_PORT, 0, port,
- data, sizeof(struct usb_hub_status), HZ);
+ data, sizeof(*data), HZ);
}
/* completion function, fires on port status changes and various faults */
@@ -272,12 +274,30 @@
wait_ms(hub-descriptor-bPwrOn2PwrGood * 2);
}
+static int usb_hub_hub_status(struct usb_hub *hub,
+ u16 *status, u16 *change)
+{
+ struct usb_device *dev = interface_to_usbdev (hub-intf);
+ int ret;
+
+ ret = usb_get_hub_status(dev, hub-status.hub);
+ if (ret 0)
+ dev_err (hubdev (dev),
+ %s failed (err = %d)\n, __FUNCTION__, ret);
+ else {
+ *status = le16_to_cpu(hub-status.hub.wHubStatus);
+ *change = le16_to_cpu(hub-status.hub.wHubChange);
+ ret = 0;
+ }
+ return ret;
+}
+
static int usb_hub_configure(struct usb_hub *hub,
struct usb_endpoint_descriptor *endpoint)
{
struct usb_device *dev = interface_to_usbdev (hub-intf);
struct device *hub_dev;
- struct usb_hub_status hubstatus;
+ u16 hubstatus, hubchange;
unsigned int pipe;
int maxp, ret;
char *message;
@@ -396,20 +416,18 @@
dev_dbg(hub_dev, hub controller current requirement: %dmA\n,
hub-descriptor-bHubContrCurrent);
- ret = usb_get_hub_status(dev, hubstatus);
+ ret = usb_hub_hub_status(hub, hubstatus, hubchange);
if (ret 0) {
message = can't get hub status;
goto fail;
}
- le16_to_cpus(hubstatus.wHubStatus);
-
dev_dbg(hub_dev, local power source is %s\n,
- (hubstatus.wHubStatus HUB_STATUS_LOCAL_POWER)
+ (hubstatus HUB_STATUS_LOCAL_POWER)
? lost (inactive) : good);
dev_dbg(hub_dev, %sover-current condition exists\n,
- (hubstatus.wHubStatus HUB_STATUS_OVERCURRENT) ? : no );
+ (hubstatus HUB_STATUS_OVERCURRENT) ? : no );
/* Start the interrupt endpoint */
pipe = usb_rcvintpipe(dev, endpoint-bEndpointAddress);
@@ -641,25 +659,20 @@
err(cannot disconnect hub %s, dev-devpath);
}
-static int usb_hub_port_status(struct usb_device *hub, int port,
+static int usb_hub_port_status(struct usb_device *dev, int port,
u16 *status, u16 *change)
{
- struct usb_port_status *portsts;
- int ret = -ENOMEM;
+ struct usb_hub *hub = usb_get_intfdata (dev-actconfig-interface);
+ int ret;
- portsts = kmalloc(sizeof(*portsts), GFP_NOIO);
- if (portsts) {
- ret = usb_get_port_status(hub, port + 1, portsts);
- if (ret 0)
- dev_err (hubdev (hub),
- %s failed (err = %d)\n, __FUNCTION__,
- ret);
- else {
- *status = le16_to_cpu(portsts-wPortStatus);
- *change = le16_to_cpu(portsts-wPortChange);
- ret = 0;
- }
- kfree(portsts);
+ ret = usb_get_port_status(dev, port + 1, hub-status.port);
+ if (ret 0)
+ dev_err (hubdev (dev),
+ %s failed (err = %d)\n, __FUNCTION__, ret);
+ else {
+ *status = le16_to_cpu(hub-status.port.wPortStatus);
+
[linux-usb-devel] Virus Detected by Network Associates, Inc. Webshield SMTP V4.5 MR1a
Network Associates WebShield SMTP V4.5 MR1a on GLOUTOON detected virus W32/[EMAIL PROTECTED] in attachment approved.pif from [EMAIL PROTECTED] and it was Deleted and Quarantined. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb_buffer_alloc flags in probe function
Alan Stern wrote: On Wed, 4 Jun 2003, Daniele Bellucci wrote: Hi, i've found some usb_buffer_alloc with GFP_KERNEL on in a probe function (kernel 2.5.70). Since probe isn't ever called in process context... is that correct? You have that exactly backwards. probe() is _always_ called in process context, in fact in the context of the khubd kernel thread. Or in the context of whatever calls usb_register() on a driver, such as modprobe. - Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
Oliver Neukum wrote: Hi, going through the drivers, it seems that there are drivers which legitimately use usb_set_configuration. It seems that we have to deal with it. Some drivers, cdc-acm, -ether, really take the whole device and try all configurations. We should remove cdc-ether.c now, 2.5 doesn't need it. As for cdc-acm, I don't think it should be doing that. The code that chooses a configuration can reasonably change its mind, for example if there was a choice and no driver could bind to that initial selection ... I don't think probe() should be allowed to change configurations. Some like empeg and other serial drivers use it where altsettings should be used. Other like tiglusb use it as a soft reset. That is, they're all using it to reset device state, including endpoints? Changing configuration from current, to zero, back to current, might be a reasonable thing to package as a generic soft reset capability. One that doesn't affect driver binding, but also doesn't involve any re-enumerate from POWERED state logic. - Dave What is to be done? Regards Oliver --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: Don't allocate transfer buffers on thestack in hub.c
Alan Stern wrote:
Does this need to be cleaned up?
Yes. I thought we had fixed all of this in the past, did we miss
something?
I think some fixes didn't get merged, for various reasons;
discussion about cache-incoherent DMA derailed a few.
This should fix things. I added buffer space (4 bytes) in struct usb_hub
to store the status reports.
Reads good, but some comments on the GET_STATUS requests:
- Those timeouts should be HZ * USB_CTRL_GET_TIMEOUT, these
are excessively short.
- Naming is problematic: usb_*() suggests they're generic
and exported, but they're not. I'd strike the usb_ prefix.
None of those are new issues, but they could be resolved now
while this code is being updated.
- Dave
--- 1.105/drivers/usb/core/hub.c Sat May 24 18:40:11 2003
+++ edited/drivers/usb/core/hub.c Wed Jun 4 11:32:10 2003
@@ -103,21 +103,23 @@
/*
* USB 2.0 spec Section 11.24.2.6
*/
-static int usb_get_hub_status(struct usb_device *dev, void *data)
+static int usb_get_hub_status(struct usb_device *dev,
+ struct usb_hub_status *data)
{
return usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_HUB, 0, 0,
- data, sizeof(struct usb_hub_status), HZ);
+ data, sizeof(*data), HZ);
}
/*
* USB 2.0 spec Section 11.24.2.7
*/
-static int usb_get_port_status(struct usb_device *dev, int port, void *data)
+static int usb_get_port_status(struct usb_device *dev, int port,
+ struct usb_port_status *data)
{
return usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_PORT, 0, port,
- data, sizeof(struct usb_hub_status), HZ);
+ data, sizeof(*data), HZ);
}
/* completion function, fires on port status changes and various faults */
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Reorganization ofdevicereset,configchange,connect,disconnect
Oliver Neukum wrote: 3. Usbfs is a security problem and needs filtering of control requests. You can use it to set a device to an occupied address thereby crashing any device. The issue is a general one with control requests. SET_ADDRESS is an interesting example, where pre-filtering ought to reject requests. But there are similar issues for SET_CONFIGURATION and SET_INTERFACE, both of which affect usbcore deeply enough to oops drivers that don't use the approved API calls. OK. How about anything but vendor specific requests needing CAP_SYS_HARDWARE ? No, that couldn't address the problem of buggy drivers. And SET_INTERFACE shouldn't need privileges; it's used for routine operations. The usbfs driver can do more internal checks, but I don't think there's a good way to catch buggy drivers that craft their own SET_* calls instead of using the usbcore calls for it. We should specify that as being illegal behavior. - Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
On 4 Jun 2003 at 9:31, David Brownell wrote: Oliver Neukum wrote: Hi, going through the drivers, it seems that there are drivers which legitimately use usb_set_configuration. It seems that we have to deal with it. Some drivers, cdc-acm, -ether, really take the whole device and try all configurations. We should remove cdc-ether.c now, 2.5 doesn't need it. As for cdc-acm, I don't think it should be doing that. The code that chooses a configuration can reasonably change its mind, for example if there was a choice and no driver could bind to that initial selection ... I don't think probe() should be allowed to change configurations. To the contrary, probe() is the only component in the system that actually understands a device configuration. The higher-level code is just blindly flipping through a list looking for help. The driver is the component that understands the attached device and should be able to determine its configuration. That's the definition of a driver, IMHO. Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: Don't allocate transfer buffers on thestack in hub.c
On Wed, 4 Jun 2003, David Brownell wrote: Reads good, but some comments on the GET_STATUS requests: - Those timeouts should be HZ * USB_CTRL_GET_TIMEOUT, these are excessively short. - Naming is problematic: usb_*() suggests they're generic and exported, but they're not. I'd strike the usb_ prefix. None of those are new issues, but they could be resolved now while this code is being updated. What about the other static routines in hub.c that use the same prefix or the same short timeout? usb_get_hub_descriptor() usb_clear_hub_feature() usb_clear_port_feature() usb_set_port_feature() hub_clear_tt_buffer() usb_hub_power_on() usb_hub_configure() usb_hub_reset() usb_hub_disconnect() usb_hub_port_status() usb_hub_port_wait_reset() usb_hub_port_reset() usb_hub_port_debounce() usb_hub_port_connect_change() usb_hub_events() usb_hub_thread() Shouldn't they all be changed? Alan Stern --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: Don't allocate transfer buffers on the stack in hub.c
--- 1.17/drivers/usb/core/hub.h Mon Oct 7 16:26:34 2002
+++ edited/drivers/usb/core/hub.h Wed Jun 4 10:37:30 2003
@@ -175,6 +175,10 @@
/* buffer for urb ... 1 bit each for hub and children, rounded up */
charbuffer[(USB_MAXCHILDREN + 1 + 7) / 8];
+ union {
+ struct usb_hub_status hub;
+ struct usb_port_status port;
+ } status; /* buffer for status reports */
int error; /* last reported error */
int nerrors;/* track consecutive errors */
It seems to me that this union needs a cacheline of its own for
noncoherent architectures. The rest looks good.
Regards
Oliver
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Reorganization of device reset,configchange,connect,disconnect
Alan Stern wrote: David: I got three messages from you all at once on this topic; I'll try to reply to them all together. There was a bit too much email on that topic for me to read it as it happened, so I caught up all at once ... :) On Mon, 2 Jun 2003, David Brownell wrote: I'm not really clear how usb_device_altered() would really need to be different from usb_device_reset() ... except (a) reset() tries to preserve device address. Why bother? The address doesn't matter. So that part doesn't need to differ from re-enumeration. (b) reset() tries to preserve driver bindings -- unless the descriptors happened to change, when it clearly won't. Why shouldn't altered() do that too, in the exceptional case that the descriptors _didn't_ change? reset() checks only that the _device_ descriptor didn't change -- and under my proposal even that wouldn't be necessary. altered() could preserve bindings if possible, but it would easier (and simpler for the drivers too) if it didn't. That doesn't answer my question though. Key point is that the two functions really don't need to be two; its a case of one coin, two sides. In short, I don't see value in having two API calls. The real issue I'm trying to address here is that there are two logically different tasks, and they are most naturally handled by two API calls. I'm pointing out that they're logically two sides of the same coin, once you consider the fault handling/recovery behaviours. What one side views as fault recovery, the other side views as the expected/desired behavior. One task (reset) is for use by drivers during error recovery: reset the device back to a known good state. The other task (altered) is for updating the core's state when the device has undergone some significant change. In principle, these two tasks could be performed by the same function. Yes. Particularly since the error handling for each task turns it into the other ... It would reset the device, then re-read the descriptors and check for changes. In the simplest form, it would unbind all the drivers if the descriptors changed at all but otherwise leave the bindings alone. In a more complicated form, it would retain the bindings for interfaces that are unchanged and remove the others -- although to me that sounds like a lot more effort than it's worth and maybe not even completely well defined. That complicated form doesn't seem necessary to me. After all, if any interfaces changed, the descriptors changed -- which is the first coin, first side. And if they didn't, it's the first coin, second side. In actual use, I expect the reset() task to be performed now and then by drivers whenever they need it for error recovery. I expect the altered() task to be carried out under highly formalized circumstances, like downloading firmware during a probe(). The driver always knows which of the two it wants, so why not provide that information to the core? Because the driver doesn't know which of the two will really end up happening: a firmware crash might cause a need to reload, or maybe descriptors didn't change after the reload and the effect is just to re-initialize internal state. Other than that synchony issue, I suspect that making the hub driver just reuse dev-children[port-1], instead of reallocation, would simplify a number of problems: both types of code can reuse the standard used every day enumeration logic. (And both should use the standard device is gone disconnect logic, used every day, in some mode, as both you and Oliver have noted in other contexts.) I must be misunderstanding what you mean here. Line 884 of hub.c (in usb_hub_port_connect_change()) is: hub-children[port] = dev; So it looks like the code already reuses the appropriate slot in the children[] array. But there's also the allocation of dev. There may be a need to flag the re-using old state path in the enumeration logic ... easily known when children[portnum-1] is non-null, or when a given descriptor handle is non-null. There aren't so many Linux drivers that load firmware after all. We can arrange to support their state transitions explicitly. For example: - EZ-USB device renumeration has a final device-initiated reset ... the hub driver will always notice a USB_STATE_* transition from ADDRESS to POWERED even in the absense of a usb_device_altered() call. That's part of why it's so easy for fxload to do it from userspace. How does the device initiate a port reset? I thought that could only happen as a result of the host setting the PORT_RESET feature. Have a look at the EZ-USB doc to see the details, which I fudged a bit. It initiates re-enumeration, I forget exactly how, and clearly can't lose power since that'd mean the firmware got lost. (It's all detailed in one of the earlier chapters in the technical reference manual, which is a big PDF doc you can download from Cypress.) - The USB Device Firmware Update (DFU) spec has a
Re: [linux-usb-devel] Use of usb_set_configuration
As for cdc-acm, I don't think it should be doing that. The code that chooses a configuration can reasonably change its mind, for example if there was a choice and no driver could bind to that initial selection ... I don't think probe() should be allowed to change configurations. To the contrary, probe() is the only component in the system that actually understands a device configuration. The higher-level code is just blindly flipping through a list looking for help. The driver is the component that understands the attached device and should be able to determine its configuration. That's the definition of a driver, IMHO. A device may have several interfaces in its configurations. Which driver shall decide? And who shall decide which driver is to decide? But of course there may be vendor specific devices whose drivers should set configuration. We need to accomodate both. The question is, how exactly? Regards Oliver --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: Don't allocate transfer buffers on thestack in hub.c
Alan Stern wrote: On Wed, 4 Jun 2003, David Brownell wrote: Reads good, but some comments on the GET_STATUS requests: - Those timeouts should be HZ * USB_CTRL_GET_TIMEOUT, these are excessively short. - Naming is problematic: usb_*() suggests they're generic and exported, but they're not. I'd strike the usb_ prefix. None of those are new issues, but they could be resolved now while this code is being updated. What about the other static routines in hub.c that use the same prefix or the same short timeout? More issues to address, yes ... :) usb_get_hub_descriptor() usb_clear_hub_feature() usb_clear_port_feature() usb_set_port_feature() hub_clear_tt_buffer() usb_hub_power_on() usb_hub_configure() usb_hub_reset() usb_hub_disconnect() usb_hub_port_status() usb_hub_port_wait_reset() usb_hub_port_reset() usb_hub_port_debounce() usb_hub_port_connect_change() usb_hub_events() usb_hub_thread() Shouldn't they all be changed? I'd rather they were. The rename is purely a cosmetic change, but there's no good reason to have the hub driver use timeouts that are so much shorter than the rest of usbcore. - Dave Alan Stern --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
[EMAIL PROTECTED] wrote: ... I don't think probe() should be allowed to change configurations. To the contrary, probe() is the only component in the system that actually understands a device configuration. The higher-level code is just blindly flipping through a list looking for help. But what we probe is an _interface_ not a device; and not a device configuration. The driver is the component that understands the attached device and should be able to determine its configuration. That's the definition of a driver, IMHO. Actually I'd say we don't yet have a component, even in userspace, which understands configuration. In fact even today, we know there are bugs in the Linux code to handle non-default configurations. I see that as a problem. One we're attacking on a few different fronts: - First, usb_set_configuration() still doesn't do what it needs to do ... the main remaining bug I know about is that changing a config (or setting it to zero) doesn't get rid of old sysfs files. - Second, that capability is unavailable from userspace, where we can expect intelligence about such policies. - Third, drivers using usb_set_configuration() have basically been wanting something other than a configuration change, since configuration changes haven't worked. (Except that the hub enumeration logic has worked for initial config 0 -- default.) We're also ignoring the power management issues, like never enabling configurations that exceed the hub's power budget. Periodically I've thought we might need to add a new notion to the API, a configuration driver. Here's a rough idea of how it might work: * New driver call, analagous to probe() but accepting a usb_device. It'd match only device descriptor fields. * Devices that need non-default configuration (index != 0) would need such driver support. * When selecting an initial configuration, usbcore would first check to see if there's a configuration driver. - If so, that driver's configure() call [or whatever] would be used ... it could set the Linux Config vs the Windows Config, or whatever. - Otherwise, use the current scheme: config index 0. Such an approach would address some of the issues that come up during enumeration. And if sysfs could be used to change the configuration, bad kernel choices could be reversed. - Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
On 4 Jun 2003 at 11:14, David Brownell wrote: [EMAIL PROTECTED] wrote: ... I don't think probe() should be allowed to change configurations. To the contrary, probe() is the only component in the system that actually understands a device configuration. The higher-level code is just blindly flipping through a list looking for help. But what we probe is an _interface_ not a device; and not a device configuration. Is that actually true? It seems that we call a probe() with an identified device, then the probe() walks through the interfaces, at least in the code I've looked at. The driver is the component that understands the attached device and should be able to determine its configuration. That's the definition of a driver, IMHO. Actually I'd say we don't yet have a component, even in userspace, which understands configuration. In fact even today, we know there are bugs in the Linux code to handle non-default configurations. I see that as a problem. One we're attacking on a few different fronts: - First, usb_set_configuration() still doesn't do what it needs to do ... the main remaining bug I know about is that changing a config (or setting it to zero) doesn't get rid of old sysfs files. - Second, that capability is unavailable from userspace, where we can expect intelligence about such policies. - Third, drivers using usb_set_configuration() have basically been wanting something other than a configuration change, since configuration changes haven't worked. (Except that the hub enumeration logic has worked for initial config 0 -- default.) We're also ignoring the power management issues, like never enabling configurations that exceed the hub's power budget. Periodically I've thought we might need to add a new notion to the API, a configuration driver. Here's a rough idea of how it might work: * New driver call, analagous to probe() but accepting a usb_device. It'd match only device descriptor fields. * Devices that need non-default configuration (index != 0) would need such driver support. * When selecting an initial configuration, usbcore would first check to see if there's a configuration driver. - If so, that driver's configure() call [or whatever] would be used ... it could set the Linux Config vs the Windows Config, or whatever. - Otherwise, use the current scheme: config index 0. Such an approach would address some of the issues that come up during enumeration. And if sysfs could be used to change the configuration, bad kernel choices could be reversed. - Dave I like the configuration driver idea, though I submit it should be an integral part of the device driver rather than a separate component. This is just based on a question of system maintenance over time. It's much easier if you have one file responsible for one device. We have an interesting problem of differentiating responsibilities among various OS components. We start out with hot-plug detect, then the enumeration drivers, then to the usb core to find the appropriate driver(s) for the device. But this pales in comparison with the complexities of unplugging ;--0 In my 30+ years of doing drivers and other hardware / software interface stuff, I've always strongly supported the idea of highly modularized code with well-delineated responsibilities. I wonder if we have the appropriate functional definitions on which to base the design of the support software? Best regards and thanks for the response. Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
On Wed, 4 Jun 2003 [EMAIL PROTECTED] wrote: The only information the core has is the vendor and product IDs. This is certainly not sufficient to determine which of multiple configurations should be used / activated. No, it's not. It is the responsibility of the driver to take control of a device if it can, including multiple dissimilar internal functions. Since it was registered with a matching vendor and product ID in the first place, it can presumably handle all aspects of that device. Normally a Linux driver handles only one aspect of the device. If a device contains multiple dissimilar internal functions, there normally will be multiple drivers loaded for it. A good example is my Brother MFC 9200C. It contains a printer, a fax machine, a scanner, and a smart-card reader. Each of these has different driver requirements, yet they should all be supported (or not support) by a single driver and a single probe() call. IMHO. They could be. But why not modularize the driver, and split it up into separate printer, fax, scanner, and card-reader drivers? Each would be easier to write and test, and might even be able to work generically on other units of the same kind, not just a Brother device. As far as selecting configurations, the argument you gave before can be taken even farther. If a single driver provides total support for a device, then presumably it also supports many different configurations, so it won't know which one to choose either! Only the user can tell. In Linux this choice is made by the user installing the proper settings in the hotplug config files. Alan Stern --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: Don't allocate transfer buffers on thestack in hub.c
On Wed, 4 Jun 2003, Oliver Neukum wrote: It seems to me that this union needs a cacheline of its own for noncoherent architectures. The rest looks good. Oliver: I would appreciate it if you (or anyone else) could post or provide a pointer to a good discussion that explains all the important issues involved in DMA coherency and cache interactions. These are tricky topics with a lot of subtleties. So here, for example, to what extent does it matter that the buffer is not allocated separately? Would moving it to the start of the whole kmalloc'ed structure solve the problem? Is this a question of each DMA master having to write in units of entire cachelines, thereby interfering with whatever data the CPU happens to store in the same cachelines? And does this also mean that it's effectively impossible to dynamically allocate any region smaller than a cacheline? Alan Stern --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
[EMAIL PROTECTED] wrote: On 4 Jun 2003 at 11:14, David Brownell wrote: [EMAIL PROTECTED] wrote: ... I don't think probe() should be allowed to change configurations. To the contrary, probe() is the only component in the system that actually understands a device configuration. The higher-level code is just blindly flipping through a list looking for help. But what we probe is an _interface_ not a device; and not a device configuration. Is that actually true? It seems that we call a probe() with an identified device, then the probe() walks through the interfaces, at least in the code I've looked at. The signature in 2.5 is: probe (struct usb_interface *, const struct usb_device_id *); And the api spec (kerneldoc) is clear that what's in question is that specific interface ... sometimes drivers will claim additional interfaces (CDC), but the probe() question is whether the driver will handle _that_ interface. It's not an invitation to claim different interfaces and leave that alone, or change the configuration (breaking other driver bindings). I like the configuration driver idea, though I submit it should be an integral part of the device driver rather than a separate component. This is just based on a question of system maintenance over time. It's much easier if you have one file responsible for one device. Likely it'd be easiest to phase in that way too. Details remain to be worked -- the main question in my mind has been how kernel code should affect the what configuration choice that needs to be made. We have an interesting problem of differentiating responsibilities among various OS components. We start out with hot-plug detect, then the enumeration drivers, then to the usb core to find the appropriate driver(s) for the device. But this pales in comparison with the complexities of unplugging ;--0 Eh? Unplug should be the _easy_ one! Everything goes away, and cleanup is straightforward. Assuming the drivers stacked over USB understand the notion of hardware gone; the SCSI code has taken a while to do that. Note that in 2.5, there's a device level hotplug event, which can be a reasonable hook for userspace to kick in a use this configuration policy if it's needed. If we need that, we'll need to remove the kernel's automagic selection of config index zero in cases where there's a real choice to be made. In my 30+ years of doing drivers and other hardware / software interface stuff, I've always strongly supported the idea of highly modularized code with well-delineated responsibilities. I wonder if we have the appropriate functional definitions on which to base the design of the support software? We're not too far from it, once we make it clear (as I think we've done in 2.5) that USB works with interface drivers. The 2.3 development cycle got things working, but left ragged edges ... 2.5 filed them down, delineating things better. That leaves what configuration as the main open issue on the enumeration path ... and all sorts of cleanups still needed on some of the funkier paths, like reset (separate thread) and the related change the firmware logic. - Dave Best regards and thanks for the response. Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
On 4 Jun 2003 at 14:50, Alan Stern wrote: On Wed, 4 Jun 2003 [EMAIL PROTECTED] wrote: The only information the core has is the vendor and product IDs. This is certainly not sufficient to determine which of multiple configurations should be used / activated. No, it's not. It is the responsibility of the driver to take control of a device if it can, including multiple dissimilar internal functions. Since it was registered with a matching vendor and product ID in the first place, it can presumably handle all aspects of that device. Normally a Linux driver handles only one aspect of the device. If a device contains multiple dissimilar internal functions, there normally will be multiple drivers loaded for it. A good example is my Brother MFC 9200C. It contains a printer, a fax machine, a scanner, and a smart-card reader. Each of these has different driver requirements, yet they should all be supported (or not support) by a single driver and a single probe() call. IMHO. They could be. But why not modularize the driver, and split it up into separate printer, fax, scanner, and card-reader drivers? Each would be easier to write and test, and might even be able to work generically on other units of the same kind, not just a Brother device. As far as selecting configurations, the argument you gave before can be taken even farther. If a single driver provides total support for a device, then presumably it also supports many different configurations, so it won't know which one to choose either! Only the user can tell. In Linux this choice is made by the user installing the proper settings in the hotplug config files. Alan Stern I'm probably going to step on some toes here, but that's OK. I think we differ in philosophy. It's nice to think in terms of tailoring a system by tweaking files here and there and loading or removing individual modules, but that's not reality. We don't have offices filled with professional system administrators to configure these systems and keep them running. Linux is an end-user product. It's purchased off the shelf by average people who take it home and expect it to work. In this environment, multiple support files are very dangerous. It's too easy to contaminate the configuration, over time and system upgrades, particularly when performed by users with limited technical skills. From a product support perspective, it's much easier to ask a user for the version of one file than to try to track down versions of a dozen different ones. Complexity translates into money. Support costs are a significant expense for software vendors. You're looking at the question from the inside out, as an OS developer. I think you could benefit from a reverse perspective, from the standpoint of the peripheral manufacturers and driver developers. They have very different concerns. Just some thoughts. Best regards. Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: Don't allocate transfer buffers on thestack in hub.c
Alan Stern wrote: And does this also mean that it's effectively impossible to dynamically allocate any region smaller than a cacheline? Only on processors with DMA-incoherent caches. Unfortunately the only way to see if you're compiling for such a system is to use architecture-specific #defines. PPC and MIPs use different ones, as I recall... --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
On Wed, 4 Jun 2003 [EMAIL PROTECTED] wrote: I think we differ in philosophy. It's nice to think in terms of tailoring a system by tweaking files here and there and loading or removing individual modules, but that's not reality. We don't have offices filled with professional system administrators to configure these systems and keep them running. Linux is an end-user product. It's purchased off the shelf by average people who take it home and expect it to work. In this environment, multiple support files are very dangerous. It's too easy to contaminate the configuration, over time and system upgrades, particularly when performed by users with limited technical skills. From a product support perspective, it's much easier to ask a user for the version of one file than to try to track down versions of a dozen different ones. Complexity translates into money. Support costs are a significant expense for software vendors. You're looking at the question from the inside out, as an OS developer. I think you could benefit from a reverse perspective, from the standpoint of the peripheral manufacturers and driver developers. They have very different concerns. Just some thoughts. Actually, I kind of agree with you. The sad fact is that no one has come up with a really satisfactory way of simplifying system administration tasks for the user. The approach of the more popular operating systems is to present a nice-looking user interface which works fine most of the time but is insufficiently powerful when something unusual comes up or things go wrong. Coupled with the way they hide and fail to document the way in which the settings are handled internally, it's not good enough for me (and maybe lots of other Linux developers). No doubt people are working on other ways to do solve this problem. In the end, I don't see the user's administrative interface to the system as being directly determined by the way in which the kernel implements its internal mechanism and policy. A nice GUI program can manipulate hotplug configuration files as easily as it can load driver modules. Alan Stern --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Reorganization of device reset,configchange,connect,disconnect
David: You last message in this thread gave me a lot to think about. I will reply to a few items in context, then discuss the rest separately. On Wed, 4 Jun 2003, David Brownell wrote: Have a look at the EZ-USB doc to see the details, which I fudged a bit. It initiates re-enumeration, I forget exactly how, and clearly can't lose power since that'd mean the firmware got lost. (It's all detailed in one of the earlier chapters in the technical reference manual, which is a big PDF doc you can download from Cypress.) I'll check it out at some point. But it still sounds strange. For the time being, let's try to ignore it. I would argue that usb_set_configuration() doesn't yet behave properly outside the stage you mention. I know for a fact that previously it didn't, and that even in the current code the sysfs files are still handled wrong. Were there other issues you're thinking of? The main open issue I'm aware of is handling the interfaces in sysfs. That's what I meant. From the standpoint of a device-driver writer it's a pretty big issue, since sysfs does the actual calls to probe() and disconnect(). So implement the hub's work_struct logic correctly. It's clearly simpler if only that one task is handling this stuff. To tell the truth, I don't care many threads handle this stuff or how the proper ordering is maintained. It's an implementation detail. Why must it be used? In thinking it over, I don't see anything bad about submitting URBs at any time, except after the struct usb_device is gone, which will never happen. Do the host drivers maintain lists of currently available endpoints, and will they get upset if the list changes while an URB is in flight? Yes, the HCDs have lists of currently active endpoints; in fact, the HC may be using them. Yes, changing them needs to be sycnchronized with usbcore, because things can break rudely if something smashes that hardware state. (Only UHCI is at all forgiving in that respect.) So when a reset or config change occurs, we will have to go through the whole process of disabling the endpoints, terminating any active URBs for those endpoints, and refusing to accept any new ones? That's pretty much already written, IIRC. If we take the simple and obviously correct path of disconnecting all drivers along the reset paths, we can allow reset completion handlers to re-bind before we kick in the sysfs code that manages other binding logic. This doesn't make sense. The only way to disconnect a driver is by calling its disconnect() routine, and when that happens the driver will erase all its saved state concerning the device. There won't be anything left to re-bind reset completion handlers or anything else to. Now you're talking about a different issue: drivers re-using state. It's why I mentioned re-using the original usbcore pointers on these reset paths, until we know it's impossible (because the descriptors changed). It's not the best handle on the device (since pointers get re-used), but it's one option. It's not a different issue. How can you talk about allowing reset completion handlers to re-bind when, for example, as a result of the disconnection the driver may have been rmmod'ed? There's no way (currently, at least) for a driver to know that it's being unbound temporarily for a reset rather than permanently. I think saving the old driver state should be the responsibility of the driver that calls usb_reset_device(), not usbcore. This is the same issue. What about other drivers bound to the device? They have no way to know the reason they are being unbound. And to re-bind them later you would have to call their probe() routine; how do you tell them that this is a re-binding rather than a new device? For that matter, why go to the trouble of unbinding the drivers at all? Wouldn't it be enough just to refuse the URBs they submit? Especially if there was a callback you could use to ask them to stop submitting for a while? The whole model of a hard reset that retains driver state has always bothered me. I don't know how we ended up with it ... in particular, did anyone even explore the notion of a soft reset, like set_config(0) then set_config(previous)? Normally the whole point of a hard reset is to re-init. We only use that hard reset in usb-storage; one of the SCSI-ish scanner drivers, where there's a FIXME untested comment; and usbfs, with 'err(this function is broken)' in the runtime ... and we get a lot of problems when usb-storage runs down those paths, too. This is a very important point. As far as I know, the reset in usb-storage was inherited from SCSI, as a last-ditch way of trying to put a device back into working order. It could be removed entirely, but it would be a shame to do that if there were any cases where it could genuinely do some good. I don't recall seeing any, largely because it hasn't worked well
Re: [linux-usb-devel] Use of usb_set_configuration -(1)
On 4 Jun 2003 at 19:29, Leigh Bassett wrote: On 4 Jun 2003 at 19:29, Oliver Neukum wrote: As for cdc-acm, I don't think it should be doing that. The code that chooses a configuration can reasonably change its mind, for example if there was a choice and no driver could bind to that initial selection ... I don't think probe() should be allowed to change configurations. To the contrary, probe() is the only component in the system that actually understands a device configuration. The higher-level code is just blindly flipping through a list looking for help. The driver is the component that understands the attached device and should be able to determine its configuration. That's the definition of a driver, IMHO. A device may have several interfaces in its configurations. Which driver shall decide? And who shall decide which driver is to decide? But of course there may be vendor specific devices whose drivers should set configuration. We need to accomodate both. The question is, how exactly? Regards Oliver The only information the core has is the vendor and product IDs. This is certainly not sufficient to determine which of multiple configurations should be used / activated. It is the responsibility of the driver to take control of a device if it can, including multiple dissimilar internal functions. Since it was registered with a matching vendor and product ID in the first place, it can presumably handle all aspects of that device. A good example is my Brother MFC 9200C. It contains a printer, a fax machine, a scanner, and a smart-card reader. Each of these has different driver requirements, yet they should all be supported (or not support) by a single driver and a single probe() call. IMHO. It should be possible to have two styles of drivers. Roughly speaking generic class drivers and vendor specific drivers. Class drivers should only consider the smallest area of management available to them, probably the interface. Vendor provided drivers will need to be able to control and manage an entire device. It may also be interesting to allow a vendor driver to request that a class driver be used for an interface. If we don't make it possible and easy for vendors to support their devices under Linux don't be suprised if they continue to not offer support for Linux. -- __O Belcarra - Embedded Linux USB Software_-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] 604-461-7532 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: Don't allocate transfer buffers on thestack in hub.c
I notice that the transfer buffer for the status URB is also part of struct usb_hub, hence not cacheline-aligned. I also notice that the contents of the buffer are never used; when a status change event occurs the driver probes all the ports and the hub itself. Would it be safe to eliminate that buffer and have the status IRQ URB request a 0-length transfer? Or would it be better to put that buffer along with the status report buffers in a separate area of memory? Having them all together shouldn't matter, because they would all be written by the same bus master. Alan Stern --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
Actually, I kind of agree with you. The sad fact is that no one has come up with a really satisfactory way of simplifying system administration tasks for the user. The approach of the more popular operating systems is to present a nice-looking user interface which works fine most of the time but is insufficiently powerful when something unusual comes up or things go wrong. Coupled with the way they hide and fail to document the way in which the settings are handled internally, it's not good enough for me (and maybe lots of other Linux developers). I would certainly never propose the type of fragile, undocumented and idiosyncratic peripheral support that we are forced to tolerate in other operating environments. That was never my intent. My concern is with the division of responsibility between the core and the device driver. My proposal is an architecture which supports device drivers which are responsible for all aspects of the configuration and operation of the devices which they support. When a device is plugged in, the core calls the registered device driver as determined by the VID/PID. The driver is responsible for configuring the device and registering supported functions with the core. By definition, the driver knows the capabilities of the device, while the core does not. At the heart of this proposal is the concept of one device / one driver. It would not preclude registration of multiple drivers for the same VID/PID pair, but this practice would be discouraged. This concept scales very nicely to both generic and vendor devices. Simple system devices (mice, keyboards, etc) could each be supported by one driver which accommodates all standard variants. Vendors can provide individual drivers for their products, and upgrade and enhance them as desired without worrying about mixing and matching components. No doubt people are working on other ways to do solve this problem. In the end, I don't see the user's administrative interface to the system as being directly determined by the way in which the kernel implements its internal mechanism and policy. A nice GUI program can manipulate hotplug configuration files as easily as it can load driver modules. Alan Stern The administrative interface can certainly implemented in a GUI, but the underlying complexity must still be addressed by a developer at some point. It's not sufficient to say let a GUI do it unless you also identify the resources to maintain that GUI. Generic drivers are not a problem. The vendor-provided drivers are very much a problem. Vendors won't expend extraordinary effort to support complex administrative environments unless they see a business advantage in doing so. Unfortunately, we are not number 1, and until we are, we have to concentrate our efforts on developing an environment that encourages others to support our system, not one which confuses and confounds their efforts. Not preaching, just thinking. Thanks for your time. Best regards, Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Reorganization of device reset, configchange,connect,disconnect
Alan Stern said: On Wed, 4 Jun 2003, David Brownell wrote: Have a look at the EZ-USB doc to see the details, which I fudged a bit. It initiates re-enumeration, I forget exactly how, and clearly can't lose power since that'd mean the firmware got lost. (It's all detailed in one of the earlier chapters in the technical reference manual, which is a big PDF doc you can download from Cypress.) So you don't have to go digging, the EZ-USB Tech Reference Manual is here: http://www.cypress.com/cfuploads/support/developer_kits/ez-usb_trm.pdf The EZ-USB FX TRM is a little harder to find: http://www.cypress.com/cfuploads/support/developer_kits/FF8EFAB3-2E98-4448-92418D0EA786766D_doc_1.pdf but the end effect seen by the host should be the same. I'll check it out at some point. But it still sounds strange. For the time being, let's try to ignore it. It sounds strange to me as well :-) Here's how I understand it: The EZ-USB chip does not really reset, it just sends a disconnect signal (by temporarily disconnecting power to the 1.5K pull-up resistor on D+ that signifies that a full-speed device is attached). This is basically done by setting a few bits, busy-waiting for a bit, and resetting the bits. David is right in saying that the chip does not lose power, and in fact, the chip does not have to reset its microcontroller core, either-- it can just respond to the control messages it gets after the host sees the new device reattaching to the bus. See page ~81 in the non-FX TRM for details. HTH, -- Charles Lepple [EMAIL PROTECTED] http://www.ghz.cc/charles/ --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
As for cdc-acm, I don't think it should be doing that. The code that chooses a configuration can reasonably change its mind, for example if there was a choice and no driver could bind to that initial selection ... I don't think probe() should be allowed to change configurations. To the contrary, probe() is the only component in the system that actually understands a device configuration. The higher-level code is just blindly flipping through a list looking for help. The driver is the component that understands the attached device and should be able to determine its configuration. That's the definition of a driver, IMHO. A device may have several interfaces in its configurations. Which driver shall decide? And who shall decide which driver is to decide? A good example of a manufactured problem. In my proposal, there is only one driver for a given device, so your questions disappear. But of course there may be vendor specific devices whose drivers should set configuration. We need to accomodate both. The question is, how exactly? Certainly there are two categories of drivers: generic and vendor. While my proposal is primarily oriented toward vendor drivers, the architecture is equally applicable to both. My goal is to simplify the vendor development environment as much as possible, since these are the people who must be convinced to get with the program ;-) Regards Oliver Thanks and best regards. Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] cut config changes from stv680
Hi, you always set the same configuration. This makes doing so quite pointless. Regards Oliver Pardon the interruption, but I don't believe you can arbitrarily remove device writes just because they appear to be redundant. I have worked with many hardware devices which required specific write sequences, and even multiple, apparently redundant, read or write accesses in order to function properly. May I suggest you be very careful where hardware interfaces are concerned. Just a suggestion. Best regards. Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
On Mer, 2003-06-04 at 23:19, [EMAIL PROTECTED] wrote: A device may have several interfaces in its configurations. Which driver shall decide? And who shall decide which driver is to decide? A good example of a manufactured problem. In my proposal, there is only one driver for a given device, so your questions disappear. This works fine for some devices - and horribly badly when the device is a mix of generic and custom interfaces. A single driver doesn;t have to mean a single kernel interface - you can be both sound card and video for example --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
[EMAIL PROTECTED] wrote: On 4 Jun 2003 at 11:14, David Brownell wrote: [EMAIL PROTECTED] wrote: ... I don't think probe() should be allowed to change configurations. To the contrary, probe() is the only component in the system that actually understands a device configuration. The higher-level code is just blindly flipping through a list looking for help. But what we probe is an _interface_ not a device; and not a device configuration. Is that actually true? It seems that we call a probe() with an identified device, then the probe() walks through the interfaces, at least in the code I've looked at. The signature in 2.5 is: probe (struct usb_interface *, const struct usb_device_id *); So this would be the appropriate point for the change to occur. And the api spec (kerneldoc) is clear that what's in question is that specific interface ... sometimes drivers will claim additional interfaces (CDC), but the probe() question is whether the driver will handle _that_ interface. It's not an invitation to claim different interfaces and leave that alone, or change the configuration (breaking other driver bindings). This is another manufactured problem. If you have only one driver, there is no question of breaking other driver bindings. I like the configuration driver idea, though I submit it should be an integral part of the device driver rather than a separate component. This is just based on a question of system maintenance over time. It's much easier if you have one file responsible for one device. Likely it'd be easiest to phase in that way too. Details remain to be worked -- the main question in my mind has been how kernel code should affect the what configuration choice that needs to be made. And again, this can be done entirely within the driver. The kernel is operating blindly in selecting a configuration. It doesn't know the difference between a mouse and a printer. It is just manipulating lists of support routine entry points. The software which understands the environment and the device capabilities resides in the driver. We have an interesting problem of differentiating responsibilities among various OS components. We start out with hot-plug detect, then the enumeration drivers, then to the usb core to find the appropriate driver(s) for the device. But this pales in comparison with the complexities of unplugging ;--0 Eh? Unplug should be the _easy_ one! Everything goes away, and cleanup is straightforward. Assuming the drivers stacked over USB understand the notion of hardware gone; the SCSI code has taken a while to do that. Note that in 2.5, there's a device level hotplug event, which can be a reasonable hook for userspace to kick in a use this configuration policy if it's needed. If we need that, we'll need to remove the kernel's automagic selection of config index zero in cases where there's a real choice to be made. In my 30+ years of doing drivers and other hardware / software interface stuff, I've always strongly supported the idea of highly modularized code with well-delineated responsibilities. I wonder if we have the appropriate functional definitions on which to base the design of the support software? We're not too far from it, once we make it clear (as I think we've done in 2.5) that USB works with interface drivers. The 2.3 development cycle got things working, but left ragged edges ... 2.5 filed them down, delineating things better. That leaves what configuration as the main open issue on the enumeration path ... and all sorts of cleanups still needed on some of the funkier paths, like reset (separate thread) and the related change the firmware logic. - Dave The simplest ( != best ;-) ) solution is to default to configuration 0 and let the driver determine whether a different selection is appropriate. Best regards. Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
On Mer, 2003-06-04 at 23:19, [EMAIL PROTECTED] wrote: A device may have several interfaces in its configurations. Which driver shall decide? And who shall decide which driver is to decide? A good example of a manufactured problem. In my proposal, there is only one driver for a given device, so your questions disappear. This works fine for some devices - and horribly badly when the device is a mix of generic and custom interfaces. A single driver doesn;t have to mean a single kernel interface - you can be both sound card and video for example Hi Alan, This conversation is becoming very complex, with multiple threads addressing different aspects of the question. I did mention in one of the other postings that multiple drivers were not precluded. It would be perfectly valid to register multiple drivers for the same VID/PID combination. This would be the exception, but it would certainly support the situations which you suggested. Thanks for your response. Best regards. Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: Don't allocate transfer buffers on thestack in hub.c
Am Mittwoch, 4. Juni 2003 20:58 schrieb Alan Stern: On Wed, 4 Jun 2003, Oliver Neukum wrote: It seems to me that this union needs a cacheline of its own for noncoherent architectures. The rest looks good. Oliver: I would appreciate it if you (or anyone else) could post or provide a pointer to a good discussion that explains all the important issues involved in DMA coherency and cache interactions. These are tricky topics with a lot of subtleties. I wish I had one myself. So here, for example, to what extent does it matter that the buffer is not allocated separately? Would moving it to the start of the whole kmalloc'ed structure solve the problem? No. Is this a question of each DMA master having to write in units of entire cachelines, thereby interfering with whatever data the CPU happens to store in the same cachelines? No, the other way round. The CPU writes whole cachelines. This corrupts parts of a cacheline not up to date in the CPU's cache. And does this also mean that it's effectively impossible to dynamically allocate any region smaller than a cacheline? Yes. Regards Oliver --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
You're looking at the question from the inside out, as an OS developer. I think you could benefit from a reverse perspective, from the standpoint of the peripheral manufacturers and driver developers. They have very different concerns. Just some thoughts. Quite sensible thoughts. What can be done simply should be done simply. We just need to discuss a lot of details. It's a complex matter. Regards Oliver --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] cut config changes from stv680
Am Donnerstag, 5. Juni 2003 00:26 schrieb [EMAIL PROTECTED]: Hi, you always set the same configuration. This makes doing so quite pointless. Regards Oliver Pardon the interruption, but I don't believe you can arbitrarily remove device writes just because they appear to be redundant. So I fear. I have worked with many hardware devices which required specific write sequences, and even multiple, apparently redundant, read or write accesses in order to function properly. May I suggest you be very careful where hardware interfaces are concerned. Yes. It needs testing by somebody with the hardware. If it turns out to be needed, we need to accomodate it. Regards Oliver --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
I like the configuration driver idea, though I submit it should be an integral part of the device driver rather than a separate component. This is just based on a question of system maintenance over time. It's much easier if you have one file responsible for one device. Likely it'd be easiest to phase in that way too. Details remain to be worked -- the main question in my mind has been how kernel code should affect the what configuration choice that needs to be made. That depends on the device. In some devices it may be obvious, others may need configuration change on the fly. [..] Note that in 2.5, there's a device level hotplug event, which can be a reasonable hook for userspace to kick in a use this configuration policy if it's needed. If we need that, we'll need to remove the kernel's automagic selection of config index zero in cases where there's a real choice to be made. No. This just encourages sloppiness :-) A configuration must be switchable by the user at any time while the device is plugged in, save for power constraints. The kernel may just as well choose a default configuration. Making distinctions here just increases complexity and means that codepaths will get less testing. In my 30+ years of doing drivers and other hardware / software interface stuff, I've always strongly supported the idea of highly modularized code with well-delineated responsibilities. I wonder if we have the appropriate functional definitions on which to base the design of the support software? We're not too far from it, once we make it clear (as I think we've done in 2.5) that USB works with interface drivers. The 2.3 development cycle got things working, but left ragged edges ... 2.5 filed them down, delineating things better. That leaves what configuration as the main open issue on the enumeration path ... and all sorts of cleanups still needed on some of the funkier paths, like reset (separate thread) and the related change the firmware logic. Let's not forget bandwidth issues. And power management. Regards Oliver --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
A device may have several interfaces in its configurations. Which driver shall decide? And who shall decide which driver is to decide? A good example of a manufactured problem. In my proposal, there is only one driver for a given device, so your questions disappear. The number of device drivers would need to increase dramatically. But of course there may be vendor specific devices whose drivers should set configuration. We need to accomodate both. The question is, how exactly? Certainly there are two categories of drivers: generic and vendor. While my proposal is primarily oriented toward vendor drivers, the architecture is equally applicable to both. We'd better call them whole device and interface drivers. My goal is to simplify the vendor development environment as much as possible, since these are the people who must be convinced to get with the program ;-) How serious is the problem? Regards Oliver --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] USB root hub polling stops after suspend
I'm running a 2.5.70 kernel (BK from a day or so ago) on my Apple titanium G4 powerbook, and it seems that the system stops polling the root hub registers when I suspend and resume the machine. The symptom is that nothing happens when I plug in a USB device after resuming. It's very annoying because it means that I can't use an external mouse after resuming. I put a breakpoint on rh_report_status, and the breakpoint was never hit. So the problem is definitely that the rh_timer has not been restarted at some point. My suspicion is that the problem is initially caused by rh_report_status returning, without restarting the timer, in the !HCD_IS_RUNNING(hcd-state) case. Subsequently, there appears to be nothing that the OHCI hcd code does (or could do) to restart the timer on resume. My question is: where should this be fixed? Should the hcd code be doing something to get the timer restarted on resume, or should the timer be kept running while the HCD is suspended? Paul. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Use of usb_set_configuration
A device may have several interfaces in its configurations. Which driver shall decide? And who shall decide which driver is to decide? A good example of a manufactured problem. In my proposal, there is only one driver for a given device, so your questions disappear. The number of device drivers would need to increase dramatically. But of course there may be vendor specific devices whose drivers should set configuration. We need to accomodate both. The question is, how exactly? Certainly there are two categories of drivers: generic and vendor. While my proposal is primarily oriented toward vendor drivers, the architecture is equally applicable to both. We'd better call them whole device and interface drivers. My goal is to simplify the vendor development environment as much as possible, since these are the people who must be convinced to get with the program ;-) How serious is the problem? Regards Oliver I don't know how serious the problem is, but I believe it does exist. May I suggest the more appropriate question would be: How easy can we make the driver development process for the vendors? Linux driver development represents an expense incurred by the vendor to support a niche market. It is incumbent upon us to facilitate the process to the greatesst extent possible if we expect Linux to be successful in the marketplace. We should not be asking Is it too horribly difficult? Rather we should ask Can we make it any easier? FWIW Best regards Leigh Bassett --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch] fix 2.4 usbdevfs race
Here's a patch to fix a race condition in usbdevfs. The fix is in hub.c
but the race is related to usbdevfs.
The race goes like this:
Process 1 (khubd) Process 2 (mount)
usb_hub_port_connect_change()
hub-children[port] = dev
usb_new_device()
usbdevfs_read_super()
recurse_new_dev_inode()
new_dev_inode()
list_add_tail(..., dev-inodes)
usbdevfs_add_device()
new_dev_inode()
list_add_tail(..., dev-inodes)
The problem is that the inode gets added twice, corrupting dev-inodes.
This will cause a problems at disconnect where the same inode will be
freed twice, causing a neverending loop, or an oops. I think it will
also cause problems at unmount.
The fix is to just move setting hub-children to later in the
enumeration process. This way usbdevfs_read_super won't see the device
before it has been through the usbdevfs_add_device path.
I didn't see this on x86, but apparentely others have looking at the
RedHat 9 kernel sources. (RedHat bugzilla #81091)
Pete, could you give this patch a shot for the problem you found in that
bug? I'm pretty sure they are the same problem.
I haven't looked at the 2.5 code to see if the same problem exists.
JE
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.4 USB kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.825 - 1.826
# drivers/usb/hub.c1.31- 1.32
#
# The following is the BitKeeper ChangeSet Log
#
# 03/06/04 [EMAIL PROTECTED] 1.826
# hub.c:
# Fix race between usbdevfs_read_super and usbdevfs_add_device
#
#
diff -Nru a/drivers/usb/hub.c b/drivers/usb/hub.c
--- a/drivers/usb/hub.c Wed Jun 4 21:17:38 2003
+++ b/drivers/usb/hub.c Wed Jun 4 21:17:38 2003
@@ -716,8 +716,6 @@
break;
}
- hub-children[port] = dev;
-
/* Reset the device */
if (usb_hub_port_reset(hub, port, dev, delay)) {
usb_free_dev(dev);
@@ -761,8 +759,10 @@
dev-bus-bus_name, dev-devpath, dev-devnum);
/* Run it through the hoops (find a driver, etc) */
- if (!usb_new_device(dev))
+ if (!usb_new_device(dev)) {
+ hub-children[port] = dev;
goto done;
+ }
/* Free the configuration if there was an error */
usb_free_dev(dev);
@@ -771,7 +771,6 @@
delay = HUB_LONG_RESET_TIME;
}
- hub-children[port] = NULL;
usb_hub_port_disable(hub, port);
done:
up(usb_address0_sem);
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch] fix 2.4 usbdevfs race
On Thu, Jun 05, 2003, Johannes Erdfelt [EMAIL PROTECTED] wrote: Here's a patch to fix a race condition in usbdevfs. The fix is in hub.c but the race is related to usbdevfs. The race goes like this: Process 1 (khubd) Process 2 (mount) usb_hub_port_connect_change() hub-children[port] = dev usb_new_device() usbdevfs_read_super() recurse_new_dev_inode() new_dev_inode() list_add_tail(..., dev-inodes) usbdevfs_add_device() new_dev_inode() list_add_tail(..., dev-inodes) The problem is that the inode gets added twice, corrupting dev-inodes. This will cause a problems at disconnect where the same inode will be freed twice, causing a neverending loop, or an oops. I think it will also cause problems at unmount. The fix is to just move setting hub-children to later in the enumeration process. This way usbdevfs_read_super won't see the device before it has been through the usbdevfs_add_device path. Thinking about it some more, I may have introduced a new race the other way. There's a chance between usbdevfs_add_device and hub-children[port] being set that a new mount can be made. It's definately a lot smaller than before (previously we had quite a few kmallocs and usb_control_msg calls which could cause context switches for many milliseconds) and not as severe (the device just won't show up on the mount instead of a BUG() call or neverending loop). I'll take a deeper look into it, but this patch should atleast be a significant improvement. JE --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
