On Fri, February 03, 2006 Alan Stern wrote: >> On Thu, 2 Feb 2006, Doug Sutherland wrote: >> I've been looking at the differences between >> the 2.4 and 2.6 gadget serial drivers and there >> don't appear to be that >> many significant >> differences (outside of the new support for the >> CDC-ACM). There are a few >> TTY functions that >> aren't included in 2.4(i.e. alloc_tty_driver(), >> tty_set_operations(), and put_tty_driver()), >> but it looks like these can easily be coded >> manually. >> >> The other main difference I see is the way the >> spinlock_t structure is passed to the spinlock >> functions. In the 2.4 version of the gadget >> serial driver, this structure is passed by >> value: >> spin_lock_irqsave( dev-dev_lock, flags ); >> >> In the 2.6 version, it seems to be passed by >> reference: >> >> spin_lock_irqsave(&dev->dev_lock, flags);
>No. In both cases the structure is passed by >reference. If the 2.4 version appears to be by >value, it must be that dev->dev_lock is a >pointer to a spinlock stucture. Or else the code >is just plain wrong. Alan, it looks like this is an outright bug in the 2.4 code because in different calls to spin_lock functions, the same spinlock_t structure element is passed by value and then later by reference. I'm not sure how this early release of the gadget_serial driver is working (it works somewhat with non-CDC/ACM host drives such as on Linux hosts). Perhaps some of these spin_lock functions resolve to nothing in my configuration. >> I don't think I really understand the >> difference here and the 2.6 code >> isn't always consistent in this regard. >Yes it is. spin_lock_irqsave _always_ takes a >pointer to a spinlock >structure. Alan, you are correct. The latest version of the gadget_serial driver is consistent - always passing a pointer to the lock structure. The older version I am currently using with 2.4 is not consistent however. >> Does anyone know what is going >> on with this spinlock issue? Is there a >> significant difference between >> 2.4 and 2.6 with regard to the spinlock >> processing? I see the spinlock.h >> files are very different between the two >> versions. Is this a real issue >> for my backporting of the gadget driver? >No, it's not a real issue. Thanks. That makes me feel more confident about the backport. I have one last question for anyone on the list. The most current version of the gadget serial driver includes the new device model header: device.h. Does anyone know what functions in the gadget serial driver make use of this include file. I will be backporting this driver to 2.4 which did not have a device.h and I'm trying to see if there is anything else that 2.4 doesn't support. Thanks, Doug ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
