[linux-usb-devel] [PATCH] [36/2many] MAINTAINERS - ALCATEL SPEEDTOUCH USB DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index b6827c1..3a586da 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -356,6 +356,8 @@ L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net W: http://www.linux-usb.org/SpeedTouch/ S: Maintained +F: drivers/usb/atm/speedtch.c +F: drivers/usb/atm/usbatm.c ALCHEMY AU1XX0 MMC DRIVER S: Orphan - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [126/2many] MAINTAINERS - CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 8b28143..7f16b33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1229,6 +1229,7 @@ P:Lennert Buytenhek M: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/host/ohci-ep93xx.c CIRRUS LOGIC CS4280/CS461x SOUNDDRIVER P: Cirrus Logic Corporation (kernel 2.2 driver) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [194/2many] MAINTAINERS - FREESCALE HIGHSPEED USB DEVICE DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 2ef0ec4..944316a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1868,6 +1868,7 @@ M:[EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net L: [EMAIL PROTECTED] S: Maintained +F: drivers/usb/gadget/fsl_usb2_udc.c FREESCALE QUICC ENGINE UCC ETHERNET DRIVER P: Li Yang - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [505/2many] MAINTAINERS - USB PRINTER DRIVER (usblp)
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index fc87fa7..02bb359 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4772,6 +4772,7 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Supported +F: /drivers/usb/class/usblp.c USB RTL8150 DRIVER P: Petko Manolov - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [506/2many] MAINTAINERS - USB RTL8150 DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 02bb359..25df49f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4781,6 +4781,7 @@ L:linux-usb-devel@lists.sourceforge.net L: [EMAIL PROTECTED] W: http://pegasus2.sourceforge.net/ S: Maintained +F: drivers/net/usb/rtl8150.c USB SE401 DRIVER P: Jeroen Vreeken - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [513/2many] MAINTAINERS - USB AUERSWALD DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 8b4d497..42830d6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4849,6 +4849,7 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/misc/auerswald.c USB SERIAL EMPEG EMPEG-CAR MARK I/II DRIVER P: Gary Brubaker - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [514/2many] MAINTAINERS - USB SERIAL EMPEG EMPEG-CAR MARK I/II DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 42830d6..df159d9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4857,6 +4857,7 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/serial/empeg.c USB SERIAL KEYSPAN DRIVER P: Greg Kroah-Hartman - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [517/2many] MAINTAINERS - USB SN9C1xx DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 91a66c9..f177a2b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4884,6 +4884,8 @@ L:linux-usb-devel@lists.sourceforge.net L: [EMAIL PROTECTED] W: http://www.linux-projects.org S: Maintained +F: Documentation/video4linux/sn9c102.txt +F: drivers/media/video/sn9c102/ USB SUBSYSTEM P: Greg Kroah-Hartman - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [516/2many] MAINTAINERS - USB SERIAL WHITEHEAT DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 25500cc..91a66c9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4875,6 +4875,7 @@ L:[EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net W: http://www.connecttech.com S: Supported +F: /drivers/usb/serial/whiteheat* USB SN9C1xx DRIVER P: Luca Risolia - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [515/2many] MAINTAINERS - USB SERIAL KEYSPAN DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index df159d9..25500cc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4866,6 +4866,7 @@ L:[EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net W: http://www.kroah.com/linux/ S: Maintained +F: drivers/usb/serial/*keyspan* USB SERIAL WHITEHEAT DRIVER P: Support Department - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [519/2many] MAINTAINERS - USB UHCI DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index ae92220..c670797 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4907,6 +4907,8 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: Documentation/usb/uhci.txt +F: drivers/usb/host/uhci* USB USBNET DRIVER FRAMEWORK P: David Brownell - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [518/2many] MAINTAINERS - USB SUBSYSTEM
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index f177a2b..ae92220 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4895,6 +4895,11 @@ L: linux-usb-devel@lists.sourceforge.net W: http://www.linux-usb.org T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ S: Supported +F: Documentation/usb/ +F: drivers/net/usb/ +F: drivers/usb/ +F: include/linux/usb.h +F: include/linux/usb/ USB UHCI DRIVER P: Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [521/2many] MAINTAINERS - USB W996[87]CF DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 4dba8ee..a5c8d86 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4925,6 +4925,8 @@ L:linux-usb-devel@lists.sourceforge.net L: [EMAIL PROTECTED] W: http://www.linux-projects.org S: Maintained +F: Documentation/video4linux/w9968cf.txt +F: drivers/media/video/w996* USB ZC0301 DRIVER P: Luca Risolia - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [522/2many] MAINTAINERS - USB ZC0301 DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index a5c8d86..16ddb78 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4935,6 +4935,8 @@ L:linux-usb-devel@lists.sourceforge.net L: [EMAIL PROTECTED] W: http://www.linux-projects.org S: Maintained +F: ocumentation/video4linux/zc0301.txt +F: drivers/media/video/zc0301/ USB ZD1201 DRIVER P: Jeroen Vreeken - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [523/2many] MAINTAINERS - USB ZD1201 DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 16ddb78..6cfd315 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4945,6 +4945,7 @@ L:[EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net W: http://linux-lc100020.sourceforge.net S: Maintained +F: drivers/net/wireless/zd1201.* USB ZR364XX DRIVER P: Antoine Jacquet - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [524/2many] MAINTAINERS - USB ZR364XX DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 6cfd315..c50b6b1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4954,6 +4954,8 @@ L:linux-usb-devel@lists.sourceforge.net L: [EMAIL PROTECTED] W: http://royale.zerezo.com/zr364xx/ S: Maintained +F: Documentation/video4linux/zr364xx.txt +F: drivers/media/video/zr364xx.c USER-MODE LINUX P: Jeff Dike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [508/2many] MAINTAINERS - USB SERIAL DIGI ACCELEPORT DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 93e31ac..b13366a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4799,12 +4799,14 @@ S: Maintained F: drivers/usb/serial/cyberjack.c USB SERIAL DIGI ACCELEPORT DRIVER -P: Peter Berger and Al Borchers +P: Peter Berger M: [EMAIL PROTECTED] +P: Al Borchers M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/serial/digi_acceleport.c USB SERIAL DRIVER P: Greg Kroah-Hartman - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [512/2many] MAINTAINERS - USB SERIAL CYBERJACK PINPAD/E-COM DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index e540357..8b4d497 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4841,6 +4841,7 @@ USB SERIAL CYBERJACK PINPAD/E-COM DRIVER L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/serial/cyberjack.c USB AUERSWALD DRIVER P: Wolfgang Muees - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [509/2many] MAINTAINERS - USB SERIAL DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index b13366a..728e53f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4814,6 +4814,10 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Supported +F: Documentation/usb/usb-serial.txt +F: drivers/usb/serial/generic.c +F: drivers/usb/serial/usb-serial.c +F: include/linux/usb/serial.h USB SERIAL BELKIN F5U103 DRIVER P: William Greathouse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [504/2many] MAINTAINERS - USB PEGASUS DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index d822865..fc87fa7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4764,6 +4764,7 @@ L:linux-usb-devel@lists.sourceforge.net L: [EMAIL PROTECTED] W: http://pegasus2.sourceforge.net/ S: Maintained +F: drivers/net/usb/pegasus.* USB PRINTER DRIVER (usblp) P: Pete Zaitcev - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [498/2many] MAINTAINERS - USB ISP116X DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index d46c083..2759bc8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4712,6 +4712,8 @@ P:Olav Kongas M: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/host/isp116x* +F: include/linux/usb/isp116x.h USB KAWASAKI LSI DRIVER P: Oliver Neukum - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [496/2many] MAINTAINERS - USB HID/HIDBP DRIVERS (USB KEYBOARDS, MICE, REMOTE CONTROLS, ...)
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index ae24def..270952c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4696,6 +4696,8 @@ M:[EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net T: git kernel.org:/pub/scm/linux/kernel/git/jikos/hid.git S: Maintained +F: Documentation/usb/hiddev.txt +F: drivers/hid/usbhid/ USB HUB DRIVER P: Johannes Erdfelt - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [497/2many] MAINTAINERS - USB HUB DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 270952c..d46c083 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4705,6 +4705,7 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/core/hub.* USB ISP116X DRIVER P: Olav Kongas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [494/2many] MAINTAINERS - USB ET61X[12]51 DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 5bec508..be2b366 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4679,6 +4679,7 @@ L:linux-usb-devel@lists.sourceforge.net L: [EMAIL PROTECTED] W: http://www.linux-projects.org S: Maintained +F: drivers/media/video/et61x251/ USB GADGET/PERIPHERAL SUBSYSTEM P: David Brownell - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [490/2many] MAINTAINERS - USB BLOCK DRIVER (UB ub)
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 228b49f..3aafacf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4644,6 +4644,7 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Supported +F: drivers/block/ub.c USB CDC ETHERNET DRIVER P: Greg Kroah-Hartman - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [489/2many] MAINTAINERS - USB ACM DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 51e9dec..228b49f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4635,6 +4635,8 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: Documentation/usb/acm.txt +F: drivers/usb/class/cdc-acm.* USB BLOCK DRIVER (UB ub) P: Pete Zaitcev - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [491/2many] MAINTAINERS - USB CDC ETHERNET DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 3aafacf..8f496de 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4653,6 +4653,8 @@ L:[EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained W: http://www.kroah.com/linux-usb/ +F: drivers/net/usb/cdc_*.c +F: include/linux/usb/cdc.h USB DAVICOM DM9601 DRIVER P: Peter Korsgaard - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [495/2many] MAINTAINERS - USB GADGET/PERIPHERAL SUBSYSTEM
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index be2b366..ae24def 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4687,6 +4687,8 @@ M:[EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net W: http://www.linux-usb.org/gadget S: Maintained +F: drivers/usb/gadget/ +F: include/linux/usb/gadget* USB HID/HIDBP DRIVERS (USB KEYBOARDS, MICE, REMOTE CONTROLS, ...) P: Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [493/2many] MAINTAINERS - USB EHCI DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index b7498bf..5bec508 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4669,6 +4669,8 @@ P:David Brownell M: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Odd Fixes +F: Documentation/usb/ehci.txt +F: drivers/usb/host/ehci* USB ET61X[12]51 DRIVER P: Luca Risolia - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [499/2many] MAINTAINERS - USB KAWASAKI LSI DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 2759bc8..94d4bac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4721,6 +4721,7 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/serial/kl5kusb105.* USB MASS STORAGE DRIVER P: Matthew Dharm - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [501/2many] MAINTAINERS - USB OHCI DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 0d6b162..94ce5ce 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4738,6 +4738,8 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Odd Fixes +F: Documentation/usb/ohci.txt +F: drivers/usb/host/ohci* USB OPTION-CARD DRIVER P: Matthias Urlichs - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [502/2many] MAINTAINERS - USB OPTION-CARD DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 94ce5ce..23b7c3d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4746,6 +4746,7 @@ P:Matthias Urlichs M: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/serial/option.c USB OV511 DRIVER P: Mark McClelland - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [503/2many] MAINTAINERS - USB OV511 DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 23b7c3d..d822865 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4755,6 +4755,7 @@ L:[EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net W: http://alpha.dyndns.org/ov511/ S: Maintained +F: drivers/media/video/ov511.* USB PEGASUS DRIVER P: Petko Manolov - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [510/2many] MAINTAINERS - USB SERIAL BELKIN F5U103 DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 728e53f..b70f5f8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4825,6 +4825,7 @@ M:[EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net S: Maintained +F: drivers/usb/serial/belkin_sa.* USB SERIAL CYPRESS M8 DRIVER P: Lonnie Mendez - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [511/2many] MAINTAINERS - USB SERIAL CYPRESS M8 DRIVER
Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index b70f5f8..e540357 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4835,6 +4835,7 @@ L:linux-usb-devel@lists.sourceforge.net S: Maintained W: http://geocities.com/i0xox0i W: http://firstlight.net/cvs +F: drivers/usb/serial/cypress_m8.* USB SERIAL CYBERJACK PINPAD/E-COM DRIVER L: [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] USB storage error on Kings 512MB Flash Drive
All, I just bought a King Usb 512MB flash drive. The device works fine with Linux kernel 2.4.21 or linux 2.4.22-pre7, but linux refuses to write past 256MB onthe device. The device in fine in Windoze, but fails with the following error in Linux: WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 3 USB Mass Storage support registered. Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: 1024000 512-byte hdwr sectors (524 MB) sda: Write Protect is off sda: sda1 sda2 sda3 sda4 SCSI device sda: 1024000 512-byte hdwr sectors (524 MB) sda: Write Protect is off sda: sda1 SCSI device sda: 1024000 512-byte hdwr sectors (524 MB) sda: Write Protect is off sda: sda1 usb-uhci.c: interrupt, status 2, frame# 1233 scsi0: ERROR on channel 0, id 0, lun 0, CDB: Read (10) 00 00 08 00 3d 00 00 02 00 Current sd08:01: sense key Medium Error Additional sense indicates Unrecovered read error I/O error: dev 08:01, sector 524290 EXT2-fs error (device sd(8,1)): read_block_bitmap: Cannot read block bitmap - block_group = 32, block_bitmap = 262145 Any suggestions? I have the full usb-storage debug ouput, The failure stems from an EPIPE error in the bulk transfer. Thanks, Joe Ceklosky --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] ldisc problem identified, now how to fix?
I think I have tracked down a problem that has been written about
recently w/r/t the Linux implementation of USB to serial (RS232C)
adapters (including modems attached via USB). I will preface my
remarks by saying I have, if you'll pardon the pun, peripheral
knowledge of what's going on, but not enough depth of Linux kernel
or USB knowledge to fix it. This is with 2.4.21.
The problem: when running an interactive session through a USB to
serial device (in my case, a Keyspan USA49WLC), as soon as the getty
hands off control to login (in my case, mgetty running /bin/login), it
sets the ldisc to the usual one, with bits OPOST and ONLCR on. The
intent is that whenever \n is seen in the output stream, \r\n actually
goes out over the device. Terminals and emulators of course expect
that \r means go to the leftmost column and \n means go down
one line. Neither alone is sufficient for newline, unless your
emulator is told that one or the other of those symbols performs both
functions (e.g., C-Kermit set terminal cr-display crlf coupled w/
setting OPOST|ONLRET).
Examining drivers/char/n_tty.c, one can see the opost() routine which
accomplishes this. If the tty's modes indicate both OPOST and ONLCR,
and the octet to be output is \n, it checks to see there are 2 octets
available in the device output buffer. If not, the write() fails. If
OK, it calls the device driver's put_char with \r, then the generic
part of the routine which outputs the char to be written, or \n in
this case. If the device driver defines a put_char routine, it is
called, but put_char is not generally defined. Therefore, the
tty_default_put_char is called. This is simply a call to the driver's
write() routine with length 1. Part of the problem is this is a
function returning void.
Now, at least in the Keyspan case, the write() routine has an
INPROGRESS flag. The generic tty driver dutifully calls the device's
write() with the data up to \n (if any), then writes a \r, then a \n.
(Remember, put_char('\r') put_char('\n') gets turned into two writes
of size 1.) The first one (of \r) goes through just fine. The second
one (of \n) however sees the INPROGRESS flag, and dutifully reports
back to its caller that the char has not been written (returns written
count != requested count, basically). The routine that called it,
serial_write(), also dutifully returns the count written. But the
problem is that particular return value is discarded because the
funtion that called it returns void. There's no retry loop or
anything.
My understanding of USB is that it's packetized, so the lowest level
driver may be arranging to have those characters sent in a packet to
the serial converter/adapter, hence the INPROGRESS. It would be
waiting for the bh to signal that the host controller has finished
with the buffer sent to it. So it's a timing issue: if there is
enough time between those requests (as when I used
insmod keyspan debug=1 with the console being a serial port), all is
just fine and the display is normal. If not, the opost() writes the
\r, and drops the \n off the face of the Earth because
tty_default_put_char() ignores the fact that request != return.
So what's the most practical solution? Can serial_write() pause until
INPROGRESS clears? Should a put_char() be added, and how should it be
implemented? Should serial_write() just accept the charater and
buffer it somehow, and write it onto the USB at some future time (such
as in the callback routines)?
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] 2.6.0-test6 include/linux/usb.h
Reduce constant string space by reusing __FILE__
--- linux-2.6.0-test5/include/linux/usb.h 2003-09-28 12:43:15.0 -0700
+++ linux-2.6.0-test6/include/linux/usb.h 2003-09-30 11:35:19.0 -0700
@@ -1038,9 +1038,9 @@
#define dbg(format, arg...) do {} while (0)
#endif
-#define err(format, arg...) printk(KERN_ERR __FILE__ : format \n , ## arg)
-#define info(format, arg...) printk(KERN_INFO __FILE__ : format \n , ## arg)
-#define warn(format, arg...) printk(KERN_WARNING __FILE__ : format \n , ## arg)
+#define err(format, arg...) printk(KERN_ERR %s: format \n , __FILE__ , ## arg)
+#define info(format, arg...) printk(KERN_INFO %s: format \n , __FILE__ , ## arg)
+#define warn(format, arg...) printk(KERN_WARNING %s: format \n , __FILE__ , ##
arg)
#endif /* __KERNEL__ */
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Extremely Strange Bug with Iomega DVDRW burner
I have an external DVD writer (Iomega Super DVD 8x write - serial DVDRW4216E2D here that has problems burning. The drive will lock up, the device goes offline and the burning program crashes. I've had the drive replaced and get the same error. I've upgraded the firmware. I've tried different types of media. I've changed cables, tried many different kernels and several different machines. The only thing in common is Linux. Now here's the weird part. If I turn on usb mass storage debugging in the kernel, the issue disappears and I get perfect burns! Might it be some sort of timing issue in the code that debugging helps overcome? I am loathe to leave on debugging all the time as I have an external USB2.0 Maxtor One Touch too. Any help appreciated. I am tearing my hair out here! Happy Christmas! scsi1 (0:0): rejecting I/O to dead device scsi1 (0:0): rejecting I/O to dead device scsi1 (0:0): rejecting I/O to dead device scsi1 (0:0): rejecting I/O to dead device scsi1 (0:0): rejecting I/O to dead device SCSI error: host 1 id 0 lun 0 return code = 400 Sense class 0, sense error 0, extended sense 0 Unable to handle kernel paging request at virtual address 6f74204f printing eip: c0220dcf *pde = Oops: [#1] PREEMPT Modules linked in: nls_iso8859_1 nls_cp437 vfat fat radeon vmnet vmmon ipv6 ds lp binfmt_misc af_packet eepro100 snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd hw_random shpchp pciehp pci_hotplug intel_agp agpgart parport_pc parport floppy irtty_sir sir_dev irda crc_ccitt tsdev mousedev joydev psmouse pcspkr rtc evdev hci_usb bluetooth sr_mod usb_storage ehci_hcd uhci_hcd usbcore i810_audio ac97_codec soundcore e100 mii yenta_socket pcmcia_core capability commoncap ide_cd cdrom ext3 jbd mbcache ide_generic piix ide_disk ide_core sd_mod ata_piix libata scsi_mod unix fbcon font vesafb cfbcopyarea cfbimgblt cfbfillrect CPU:0 EIP:0060:[c0220dcf]Tainted: P VLI EFLAGS: 00210047 (2.6.9-1-686) EIP is at as_insert_request+0x8f/0x180 eax: 6f74204f ebx: cfad2240 ecx: 0001 edx: esi: c1269cb0 edi: ebp: esp: c6645d70 ds: 007b es: 007b ss: 0068 Process growisofs (pid: 9759, threadinfo=c6644000 task=c08f1020) Stack: c6644000 00200086 c6645da4 cf8f1270 c1269cb0 0001 00200202 c0217ef5 cf8f1270 c1269cb0 0001 c1269cb0 0001 cf8f1270 c021a837 cf8f1270 c1269cb0 0001 c6645e08 c1269c00 cfa7e618 d09251a0 Call Trace: [c0217ef5] __elv_add_request+0x45/0xb0 [c021a837] blk_insert_request+0x77/0xe0 [d087d1a8] scsi_insert_special_req+0x38/0x40 [scsi_mod] [d087d448] scsi_wait_req+0x68/0xa0 [scsi_mod] [d087d350] scsi_wait_done+0x0/0x90 [scsi_mod] [d0922562] sr_do_ioctl+0x92/0x2a0 [sr_mod] [d0922245] sr_packet+0x25/0x40 [sr_mod] [d0871865] cdrom_get_disc_info+0x65/0xb0 [cdrom] [d086d76b] cdrom_mrw_exit+0x1b/0x70 [cdrom] [c01b8e60] kobject_release+0x0/0x10 [c01b9229] kref_put+0x39/0xa0 [d086d354] unregister_cdrom+0x94/0xe0 [cdrom] [d09222a2] sr_kref_release+0x42/0x70 [sr_mod] [d0922260] sr_kref_release+0x0/0x70 [sr_mod] [c01b9229] kref_put+0x39/0xa0 [c01b8e8f] kobject_put+0x1f/0x30 [d09217b2] sr_block_release+0x72/0x90 [sr_mod] [d0922260] sr_kref_release+0x0/0x70 [sr_mod] [c0160e9a] blkdev_put+0x17a/0x1a0 [c0158ede] __fput+0x11e/0x130 [c01574d9] filp_close+0x59/0x90 [c0157571] sys_close+0x61/0xa0 [c010615b] syscall_call+0x7/0xb Code: 00 00 00 00 f6 46 08 0c 0f 85 c8 00 00 00 83 fd 02 74 79 7f 47 4d 74 10 0f 0b 10 06 60 86 2b c0 83 c4 10 5b 5e 5f 5d c3 8b 43 34 8b 10 89 72 04 89 16 89 46 04 89 30 90 8d 74 26 00 89 74 24 04 6note: growisofs[9759] exited with preempt_count 2 bad: scheduling while atomic! [c029c29c] schedule+0x4ec/0x500 [c0147483] unmap_page_range+0x53/0x80 [c0147666] unmap_vmas+0x1b6/0x1d0 [c014be0d] exit_mmap+0x7d/0x160 [c011b825] mmput+0x65/0xb0 [c01201ba] do_exit+0x15a/0x420 [c010745d] die+0x18d/0x190 [c011dcd7] printk+0x17/0x20 [c01184b2] do_page_fault+0x242/0x5cd [d08cb1a0] __ide_dma_read+0xd0/0xe0 [ide_core] [d08ca8e0] ide_dma_intr+0x0/0xb0 [ide_core] [c0119648] recalc_task_prio+0xa8/0x1a0 [c01197a2] activate_task+0x62/0x80 [c01198a6] try_to_wake_up+0xa6/0xc0 [c0118270] do_page_fault+0x0/0x5cd [c0106bfd] error_code+0x2d/0x38 [c0220dcf] as_insert_request+0x8f/0x180 [c0217ef5] __elv_add_request+0x45/0xb0 [c021a837] blk_insert_request+0x77/0xe0 [d087d1a8] scsi_insert_special_req+0x38/0x40 [scsi_mod] [d087d448] scsi_wait_req+0x68/0xa0 [scsi_mod] [d087d350] scsi_wait_done+0x0/0x90 [scsi_mod] [d0922562] sr_do_ioctl+0x92/0x2a0 [sr_mod] [d0922245] sr_packet+0x25/0x40 [sr_mod] [d0871865] cdrom_get_disc_info+0x65/0xb0 [cdrom] [d086d76b] cdrom_mrw_exit+0x1b/0x70 [cdrom] [c01b8e60] kobject_release+0x0/0x10 [c01b9229] kref_put+0x39/0xa0 [d086d354] unregister_cdrom+0x94/0xe0 [cdrom] [d09222a2] sr_kref_release+0x42/0x70 [sr_mod] [d0922260]
Re: [linux-usb-devel] Extremely Strange Bug with Iomega DVDRW burner
--- Alan Stern [EMAIL PROTECTED] wrote: You can try enabling the time delay feature of the usb-storage driver. It's in the source file drivers/usb/storage/transport.c, a call to the udelay() routine (search for udelay in the file). The call is protected by a test, so it only gets made for devices manufactured by Genesys Logic. You can comment out the test, so that the delay always happens. Goodness knows whether this will solve your problem, but it's worth a try. It worked perfectly! I just had my first proper burn without debugging on. I suppose the next step is to put in place a test so this delay only applies to this peculiar device. By the way, none of the devices in your /proc/bus/usb/devices listing appears to be an Iomega DVDRW. Did it not show up in the listing for some reason? Whoops! The drive had gone offline after a failed burn when I took that listing. The full listing is now below. thanks again! T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 1, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.9 ehci_hcd S: Product=Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller S: SerialNumber=:00:1d.7 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms T: Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=050d ProdID=0234 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms T: Bus=04 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2040 ProdID=2900 Rev= 4.00 S: Manufacturer=Hauppauge S: Product=USB Device C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms T: Bus=04 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0d49 ProdID=7000 Rev= 2.00 S: Manufacturer=Maxtor S: Product=OneTouch S: SerialNumber=Y64HRFJE C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=32ms T: Bus=04 Lev=02 Prnt=02 Port=02 Cnt=03 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=059b ProdID=015d Rev= 0.02 S: Manufacturer=IOMEGA S: Product=DVDRW8440E2D-B S: SerialNumber=0410200937 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 96mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us T: Bus=04 Lev=02 Prnt=02 Port=03 Cnt=04 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0db0 ProdID=1967 Rev= 5.25 C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none) T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.9 uhci_hcd S: Product=Intel
Re: [linux-usb-devel] Extremely Strange Bug with Iomega DVDRW burner
False alarm :( While the burns complete, the DVDs produced are all unreadable. I've tried both the old drive and the replacement and the same happens. They both have different firmware btw. All I did was comment out the if statement before the udelay() so as to make it always happen. It worked perfectly! I just had my first proper burn without debugging on. I suppose the next step is to put in place a test so this delay only applies to this peculiar device. __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Extremely Strange Bug with Iomega DVDRW burner
At this point it sounds like the USB transport is working correctly and the data is going to/from the burner okay. It may be that the DVDs end up unreadable because of some error in the way the DVD-writer application is used. Check your system log for error messages from usb-storage. If there aren't any, and the device indicates that the data transfers are all working well, then I don't see what more can be fixed (at this level, anyway). Alan Stern Hi Alan, I just made verifiable good burn. I made two changes. I flashed my drive with an even newer firmware and I switched from growisofs to cdrecord-ProDVD. Now I have at least one good burn. I'll try a few more and see what happens, Happy Christmas and thanks again! __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Extremely Strange Bug with Iomega DVDRW burner
--- David Brownell [EMAIL PROTECTED] wrote: On Friday 24 December 2004 2:46 pm, you wrote: At this point it sounds like the USB transport is working correctly and the data is going to/from the burner okay. It may Where sounds like is not convincing to me, given bugfixes in 2.6.10-rc3-bk ... you really should try this with a newer kernel... Did all the changes you mention make it into the just released 2.6.10? __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] usb floppy drive
I'm very close to having the USB floppy drive on my Sony Vaio working correctly -- all that's left is getting it to insmod the sd_mod module automatically when I plug in the drive (it is insmod'ing the scsi_mod and usb-storage modules). So, near as I can tell, this means an entry for the drive needs to be added to /lib/modules/2.4.6/modules.usbmap (if possible) or /etc/hotplug/usb.handmap. Looking at http://linux-hotplug.sourceforge.net/?selected=usb it appears that modules.usbmap is created by depmod -a. How? Is there a database somewhere I should be able to edit to include the drive? Alternatively, reading usb.handmap, it is documented as being in ``modutils format.'' So... where is modutils format documented? Alternatively, is there already an entry for a Y-E Data, Inc. FlashBuster-U floppy drive? I notice it is in the device ID list at http://www.linux-usb.org/usb.ids. I should mention that I'm running debian hotplug version 0.0.20010919-2 -- Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605 Department of Computer Science FAX -- (505) 646-1002 New Mexico State University http://www.cs.nmsu.edu/~pfeiffer Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Two USB cameras
With the 3com homeconnect driver I've written I have a user reporting that he is using 8 cameras simultaneously. Of course he is only grabbing one image from each every few seconds. He has recently switched over to using camserv (http://www.sourceforge.net/projects/cserv) which allows an automated script to pick up single frames and archive them but someone with a web browser can get a streaming feed. (it's being used for a NOC security system apparently) So, yeah. Works fine. As others have said though it's fairly difficult to stream from two cameras simultaneously because image acquisition takes up too much of USB's bandwidth. On Friday 19 April 2002 06:28 am, Derek Cassidy wrote: Has anyone tried viewing two cameras at the same time on Linux? I have two OV511 cameras connected to each of the usb ports and they load fine onto /dev/video0 and /dev/video1 but I cannot view both of them at the same time? I've tried xawtv and gqcam Derek ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] usb-storage errors from SCSI
All, I have one of the USB/IDE bridge controller connected to an IBM IDE HD. When using 2.4.19, a USB 1.1 controller and the usb-uhci drivers; during a massive copy of say 4 gigs to the drive I will see SCSI error 7000 on some sectors and the machine gets chugged up. The errors repeat for a bit then go away and eventually the copy completes. The files appear to be in fine. I know the HD is fine because I can take the same drive and controller combination on a USB 2.0 machine with ehci drivers and never see an error. Any thoughts on this or what I can do to help debug. It seems like the HDC can't handle all of this load and reports the SCSI errors at times. With small copies, I never see any problems on USB 1.1 or 2.0 Please respond to [EMAIL PROTECTED] Thanks, Joe --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: About the vicam driver(s)
I'd hope for keeping just one version in the kernel, otherwise the companies making distros are going to have a terrible time with it... There are a couple important things my driver does that John's doesn't, but there is one very important thing that John's driver did that mine doesn't: asynchronous frame grabs. If John has the inclination, a patch to my 2.5.41 driver to do asynchronous streaming rather than synchronous streaming would be a great boon to whole community. Also I know John had some discussion with some of the others about race conditions and semaphores, it'd be great to have any of those still in existence were fixed. Everyone can share the credit and hopefully everyone - developer and user alike - will be happy. My opinion now is that the sourceforge project has performed its service flawlessly but should now be retired and all future work done as patches against the official versions in the kernel. As Greg said to me in an earlier email - there wouldn't have been any confusion if I had done my work against the version in the kernel to begin with. At 11:11 AM 10/14/2002 -0700, John Tyner wrote: I don't know how much Joe knows about all of this, but here goes. :) I actually felt that I was taking away from the sourceforge guys buy writing my driver. Like I said (to Greg) before, I actually had no original intention of posting my driver as Joe and those working with him actually did a lot of the legwork. I'm not actually trying to compete, I just want to get my camera working. That said, I think that there are things in each driver that the other doesn't do or doesn't do as well (in my opinion) and that people would best be served by trying to merge both rather than having them compete. I'm more than willing to submit patches to reach this end. Perhaps that's where I should have started, but as I also said before (to Greg) I wrote a separate driver partly as a learning experience and partly to get my camera working a little bit faster. John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] convert proc use to driverfs in vicam.c
At 11:57 AM 10/23/2002 +0200, Oliver Neukum wrote: Why would teaching applications your ioctl be harder than teaching them your customs procfs or driverfs file? From a coding point of view an ioctl on a file you do a lot of ioctls on anyway is far simpler than deducing a path to another file, opening it and writing an ASCII value into it. Which is racy by the way, unless you revalidate the file. It is easier to teach applications to use my ioctl. However that doesn't much matter because they won't learn it. The proc entry is not meant for apps to use, it's meant for users. Since the apps won't adjust the shutter speed, I've given users a simple mechanism to do so. You are offering a nonstandard feature. It needs special support in any case. Those who can rig their own shell scripts can compile a simple C programm, too. Users will react much better to a special feature that uses a tool they already have and are familiar with (echo) than any custom app I can give them. Especially since this allows them to adjust shutter speed while looking at the image. A custom ioctl app would not. While that is true, V4L2 is not here yet and won't come into 2.4. So I suggest that you leave out the shutter speed setting until it is clear whether V4L2 is in 2.6/3.0. Leaving out the shutter speed will make the driver unusable in all but a small set of situations. --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: About the vicam driver(s)
At 10:06 PM 10/17/2002 -0700, you wrote: The use of the dev_set_drvdata family of calls. I'm not sure why, but those seem to keep the driver from being inserted, removed, and reinserted. Replacing those with the use of private_data field in the usb_interface struct seems to fix that (I removed the usb_put_device call along with these, so that my be to blame instead). I'm not sure why those are a problem either. The dev_set_drvdata calls were used because the cpia driver uses them. I've used the cpia driver as my example of a webcam driver that works. I've probably misused something in the process. The control message allocation and async urbs, as previously mentioned. The is_initialized and needsDummyRead variables are unneeded as the things protected by those variables can/should just be done when the camera is initialized. You're actually looking at a bug there. The proc interface for the shutter (which you don't seem to like) should be setting needsDummyRead. As the code says, the camera doesn't take changes in shutter speed until the frame after the one you capture. Any time shutter speed changes, you need to do a dummy read to get a properly exposed image. The disconnect handling is wrong for the same reasons mine was. There is no synchronization with the open/release routines, no making sure that no communication with the camera is going on, and the cam structure is freed without checking if users still have the camera open. framebuf is allocated in both open and mmap calls. Not necessarily wrong... however, it is possible that if the pointer was overwritten that the memory would just be reallocated/leaked instead of oopsing, which would indicate a problem. In both places, framebuf is only allocated if it is not already allocated. I think in both places the allocation is protected by a semaphore. Maybe it is wrong, could you give you more info? There are some other, more subjective things that I take issue with such as the read function being unnecesarily complicated, the proc interface not being necessary, raw_image being allocated in open rather than probe, etc. The read function is written as such because the early usblib-based camera control software was heavily used and I wanted to make it possible for the already existing scripts to work as they had before. Thus the complexity of my read function is there so that users could do: cp /dev/video/video0 mypic.raw and it would work. The raw file could then be sent through ImageMagick to convert it into something usable. I don't mind the proc interface going provided that there is a way to change the shutter speed independently for every camera connected. I have a lot of experience with users of this camera. Some have the camera up a tree (looking at scenes that vary in lighting throughout the day) and some have many cameras connected to a security monitoring system (with different cameras being under different lighting conditions). The gain control does not have enough range to cope with this, and gain degrades image quality anyway. Some of these things are easy, some are a bit more complicated. My biggest issue is that the driver that I submitted is a superset of the one that was merged. I did a lot of work to write/test/debug/etc. that code, and my doing that again would be a step backwards, in my mind. Here's why I disagree: Shutter speed. I'm not sure why, your code to set up the frame request packet looks a lot like my code to do the same, but you only included the slow shutter speed calculation. You also have a shutter speed bug, the camera can't actually capture anything slower than 1/4 sec. (it will take the value, but not give you the exposure). Superior Color decode. Your color decoder looks like a lightly touched version of Andy Armstrong's original color decoder. In my driver I decided not to use that one, opting instead for Monroe Williams' better color decoder. Removed V4L bug. Your V4L code looks like a modified copy of my 3comhc.c driver, right down to a bug in VIDIOCMCAPTURE. In any case, I will assume responsibility for merging and debugging if you are not interested. I was of the opinion that if my driver were modified to include proper disconnect protection and asynchronous captures the driver would be feature complete until we reverse engineer the formats other than 512x242. -Joe --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576298;k? http://www.sun.com/javavote ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: About the vicam driver(s)
At 11:34 AM 10/21/2002 -0700, John Tyner wrote: You're actually looking at a bug there. The proc interface for the shutter (which you don't seem to like) should be setting needsDummyRead. As the Well, that makes more sense. I'm not against what the proc interface is trying to achieve so much as the way it is achieved. It takes quite a bit of code (setup, parsing, etc) to create an interface that would probably be better provided through an ioctl if at all possible. Mine wasn't the first V4L driver to support this type of functionality. Using the current mechanism, a user needs nothing more than echo to change the shutter speed. Using a custom IOCTL, the user would require a stand alone vicam-specific executable to change the shutter speed. I didn't think that was a reasonable expectation. In both places, framebuf is only allocated if it is not already allocated. I think in both places the allocation is protected by a semaphore. Maybe it is wrong, could you give you more info? It's not wrong, per se. IMO, it's bad style. The memory should be allocated in one place when the camera is initialized (or perhaps even in the mmap call since it may not be needed until there (mine needs it before then)). The fact that you allocated it twice could lead to a memory leak if you were to ever accidentially overwrite your pointer. The memory should definitely not be allocated when the camera is initialized. I think there are a few who would throw a fit if your driver was allocating 320*240*3*2 bytes of data (nearly half a megabyte) any time the camera was plugged in but only got used if a V4L application started up. The only appropriate single place for this I would think in open (assuming that mmap cannot possibly be called before open). Thus scrubbing the allocation from mmap would clear up this issue. Two things, the V4L API states that each successive call to read should return the next image from the device. There isn't really a need to support multiple reads over the same frame (though it is nice to the user :) ). Second, I understand what you're trying to achieve and still think that read is more complicated than it needs to be. I can submit a patch showing what I think it should be. The V4L API also says that applications should provide a suitably sized read buffer. An application which does this, will receive the expected V4L behavior from my driver. An application which does not, would break on any other camera. I'd be happy to see read replaced with something simpler provided that it allows a user using simple shell commands to capture images from the camera. I think it is a benefit to users to be able to capture images with a shell script from the webcam and not be required to use a V4L tool. If we're really concerned about well behaved V4L drivers, both of our drivers should be discarded. They both violate at least two of the well behaved requirements. I don't mind the proc interface going provided that there is a way to change the shutter speed independently for every camera connected. I have Is it possible to add it to an ioctl or perhaps one of the existing ones? (This is probably a V4L issue.) There are no V4L ioctl's that map to shutter speed. I only mapped gain to brightness because everybody else does to the point that some applications (such as gqcam) use this in an attempt to auto adjust exposure. The range on the shutter is 4 to 31500, not many applications have controls with that much range if I were to map it to something like contrast. It is a V4L issue that is sorted out in V4L2. But I still rather like the fact that without using any V4L apps, a user can write a shell script and use Image Magick to create a viewable gif/jpg/png/whatever. I can send you the latest version of my working copy (I still play with it some as a hobby), and you're welcome to use it as a guide to the async urbs if you so desire. I'll also try to assist if I can provide insight into what I did to make it happen. I just can't be the one to take the lead on this issue. Sounds reasonable to me. Oliver hammered me pretty hard :) to get my disconnect handling into shape. As time allows, I think I'd be a little more willing to look at and try to fix that part up. Any patches are welcome. --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: About the vicam driver(s)
At 03:55 PM 10/21/2002 -0700, John Tyner wrote: Is a MODULE_PARM too unreasonable? I agree that the proc interface provides a simple way to change the shutter speed, but I still think that it's a lot of code to do a small amount of work. Maybe a standalone app is too much to ask, but [personally] I'd like something other than proc. A MODULE_PARM is not too unreasonable, provided it: 1) Can be set at any time while the camera is plugged in. We can be a little flexible on that, but it absolutely without question must be alterable while the device is open and being used by an application. 2) A different shutter speed can be specified for each camera connected. I have four cameras. Other people have reported using as many as 8. We cannot have one parm affecting shutter speed on all 8 of those cameras. I'd also not like to limit the number of cameras that can be plugged in just for sake of shutter speed adjustment. 3) Can easily be set by the user without having to use any hex/binary math. If you don't intend to use the camera, why plug it in? If you want to plug it in, why not leave the driver as an unloaded module? cp and dd are not V4L applications, but they would cause this memory to be allocated. As previously mentioned, the average user will leave the camera plugged in whether they are using it or not unless they have some reason to unplug it (like needing the USB port). Their distribution will automatically insert the driver for the device upon detection. It is unreasonable to require half a meg per camera plugged in if that camera is not in use. It is reasonable for cp and dd to have that memory allocated because they are using the camera. Is it reasonable for cp/dd to allocate and free that memory each time they run? I think it is, but I'm not sure I free the memory on close. If not, I should. I submitted a patch earlier to show what I meant. I can submit another which will probably break cp but will work with any application that supplies a big enough buffer (dd works with it). Is that sufficient? I haven't had a chance to look at your patch yet, but I promise I will look at your latest one within 24 hours. And I'm not opposed to it. But I think that the driver's primary responsibility should be to V4L apps, and if we can make shell utils work as a side effect, cool. But they should take a back seat to V4L. I think a reasonable set of requirements for read is: 1) Applications that read in a number of bytes equal to one whole frame, will receive subsequent frames on each read. This is keeping with the V4L spec. 2) Applications that read less than one whole frame's worth of bytes will receive fragments of a single frame until it has read one whole frame. Thus `cat /dev/video0 mypic` will work. (I think I may have been wrong about using cp, my posts on sourceforge only indicate cat working) I believe the current read function does this. Many months ago the first incarnation of the driver had a V4L bug that prevented mmap from working, so some applications like gqcam ended up reading from /dev/video. It worked perfectly and the read code hasn't changed since then so I assume it still does. There may be more efficient ways of accomplishing the same thing, again I'll look at your patch. I'm willing to back off of some of this stuff if others think I'm wrong, but so far no one has spoken up. I think most just see vicam in the subject and skip the content :) I know I only read a fraction of all the messages flying across all the linux development lists I'm subscribed to. There just aren't enough hours in a day to read and think about them all. -Joe --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH] drivers/usb/media/vicam.c: simplify vicam_read
At 09:52 PM 10/21/2002 -0700, John Tyner wrote:
This is in addition to the previous patch. It should allow any programs
that read entire frames to receive a new frame with each successive read.
Programs that read less than the entire frame will read until they reach
the end of the frame. They will then read 0 bytes (signifying EOF). The
next read will start the next frame.
I like the much simpler code! It has two small, fixable issues in vicam_read:
You no longer check buf against NULL, can a misbehaved program cause a
problematic seg fault in the kernel?
from your patch file:
+ down_interruptible(cam-busy_lock);
[...]
+ if (*ppos = VICAM_MAX_FRAME_SIZE) {
+ *ppos = 0;
+ return 0;
}
I'm betting that semaphore needs to be upped before returning :)
Also, I fixed the problem with insmod vicam / rmmod vicam / insmod vicam
seg faulting.
Here's the patch against 2.5.44:
--- linux-2.5.44/drivers/usb/media/vicam.c Mon Oct 21 14:09:13 2002
+++ linux-2.5.44-vicam/drivers/usb/media/vicam.cTue Oct 22 02:25:05
2002
@@ -1,6 +1,7 @@
/*
* USB ViCam WebCam driver
- * Copyright (c) 2002 Joe Burks ([EMAIL PROTECTED])
+ * Copyright (c) 2002 Joe Burks [EMAIL PROTECTED]
+ * Copyright (c) 2002 John Tyner [EMAIL PROTECTED]
*
* Supports 3COM HomeConnect PC Digital WebCam
*
@@ -41,7 +42,7 @@
#include linux/proc_fs.h
#include usbvideo.h
-// #define VICAM_DEBUG
+#define VICAM_DEBUG
#ifndef MODULE_LICENSE
#define MODULE_LICENSE(a)
@@ -421,9 +422,6 @@
u8 bulkEndpoint;
bool needsDummyRead;
- u32 framebuf_size; // # of valid bytes in framebuf
- u32 framebuf_read_start;// position in frame buf that a
read is happening at.
-
#ifdef CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
#endif
@@ -754,9 +752,9 @@
printk(KERN_ERR
vicam video_device improperly initialized);
}
-
+
down_interruptible(cam-busy_lock);
-
+
if (cam-open_count 0) {
printk(KERN_INFO
vicam_open called on already opened camera);
@@ -782,15 +780,15 @@
}
}
// First upload firmware, then turn the camera on
-
if (!cam-is_initialized) {
initialize_camera(cam);
+ DBG(Firmware uploaded);
cam-is_initialized = 1;
}
set_camera_power(cam, 1);
-
+
cam-needsDummyRead = 1;
cam-open_count++;
@@ -924,6 +922,11 @@
int n;
int actual_length;
+ if (cam-needsDummyRead) {
+ cam-needsDummyRead = 0;
+ read_frame(cam, framenum);
+ }
+
memset(request, 0, 16);
request[0] = cam-gain; // 0 = 0% gain, FF = 100% gain
@@ -974,74 +977,37 @@
vicam_decode_color(cam-raw_image,
cam-framebuf +
framenum * VICAM_MAX_FRAME_SIZE );
-
- cam-framebuf_size =
- 320 * 240 * VICAM_BYTES_PER_PIXEL;
- cam-framebuf_read_start = 0;
-
- return;
-
}
static int
vicam_read( struct file *file, char *buf, size_t count, loff_t *ppos )
{
struct vicam_camera *cam = file-private_data;
- DBG(read %d bytes.\n, (int) count);
- if (!buf)
- return -EINVAL;
+ DBG(read %d bytes.\n, (int) count);
- if (!count)
- return -EINVAL;
+ down_interruptible(cam-busy_lock);
- // This is some code that will hopefully allow us to do shell
copies from
- // the /dev/videoX to a file and have it actually work.
- if (cam-framebuf_size != 0) {
- if (cam-framebuf_read_start == cam-framebuf_size) {
- cam-framebuf_size = cam-framebuf_read_start = 0;
- return 0;
- } else {
- if (cam-framebuf_read_start + count =
- cam-framebuf_size) {
- // count does not exceed available bytes
- copy_to_user(buf,
-(cam-framebuf) +
-cam-framebuf_read_start, count);
- cam-framebuf_read_start += count;
- return count;
- } else {
- count =
- cam-framebuf_size -
- cam-framebuf_read_start;
- copy_to_user(buf,
-(cam-framebuf) +
-cam-framebuf_read_start, count);
- cam-framebuf_read_start = cam-framebuf_size;
- return count;
- }
- }
+ if (*ppos = VICAM_MAX_FRAME_SIZE) {
+ *ppos = 0;
+ return 0;
}
- down_interruptible(cam
Re: [linux-usb-devel] Re: [PATCH] drivers/usb/media/vicam.c: simplify vicam_read - ignore my patch
At 03:55 AM 10/22/2002 -0700, Joe Burks wrote:
from your patch file:
+ down_interruptible(cam-busy_lock);
[...]
+ if (*ppos = VICAM_MAX_FRAME_SIZE) {
+ *ppos = 0;
+ return 0;
}
I'm betting that semaphore needs to be upped before returning :)
Now if only I had upped it in my patch... Ignore that last patch. I'm
going to sleep and I'll re-submit (this time with the up) tomorrow.
-Joe
---
This sf.net emial is sponsored by: Influence the future of
Java(TM) technology. Join the Java Community Process(SM) (JCP(SM))
program now. http://ad.doubleclick.net/clk;4699841;7576301;v?
http://www.sun.com/javavote
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] linux-2.5.44/drivers/usb/media/vicam.c
This is a bug fixing patch against 2.5.44, it contains
John Tyner's simplified vicam_read
Bug fixes per Oliver Neukum
Other assorted bug fixes
--- linux-2.5.44/drivers/usb/media/vicam.c Mon Oct 21 14:09:13 2002
+++ linux-2.5.44-vicam/drivers/usb/media/vicam.cTue Oct 22 11:18:15
2002
@@ -1,6 +1,7 @@
/*
* USB ViCam WebCam driver
- * Copyright (c) 2002 Joe Burks ([EMAIL PROTECTED])
+ * Copyright (c) 2002 Joe Burks [EMAIL PROTECTED]
+ * Copyright (c) 2002 John Tyner [EMAIL PROTECTED]
*
* Supports 3COM HomeConnect PC Digital WebCam
*
@@ -39,9 +40,10 @@
#include linux/vmalloc.h
#include linux/slab.h
#include linux/proc_fs.h
+#include linux/ctype.h
#include usbvideo.h
-// #define VICAM_DEBUG
+//#define VICAM_DEBUG
#ifndef MODULE_LICENSE
#define MODULE_LICENSE(a)
@@ -421,9 +423,6 @@
u8 bulkEndpoint;
bool needsDummyRead;
- u32 framebuf_size; // # of valid bytes in framebuf
- u32 framebuf_read_start;// position in frame buf that a
read is happening at.
-
#ifdef CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
#endif
@@ -748,27 +747,30 @@
struct video_device *dev = video_devdata(file);
struct vicam_camera *cam =
(struct vicam_camera *) dev-priv;
+ int ret = 0;
+
DBG(open\n);
if (!cam) {
printk(KERN_ERR
vicam video_device improperly initialized);
}
-
- down_interruptible(cam-busy_lock);
-
+
+ if ( down_interruptible(cam-busy_lock) )
+ return -EINTR;
+
if (cam-open_count 0) {
printk(KERN_INFO
vicam_open called on already opened camera);
- up(cam-busy_lock);
- return -EBUSY;
+ ret = -EBUSY;
+ goto fail;
}
if (!cam-raw_image) {
cam-raw_image = kmalloc(VICAM_MAX_READ_SIZE, GFP_KERNEL);
if (!cam-raw_image) {
- up(cam-busy_lock);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto fail;
}
}
@@ -776,21 +778,28 @@
cam-framebuf =
rvmalloc(VICAM_MAX_FRAME_SIZE * VICAM_FRAMES);
if (!cam-framebuf) {
- kfree(cam-raw_image);
- up(cam-busy_lock);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto fail;
}
}
// First upload firmware, then turn the camera on
-
if (!cam-is_initialized) {
- initialize_camera(cam);
+ if ( initialize_camera(cam) 0 ) {
+ DBG(Error during firmware upload.\n);
+ ret = -EIO;
+ goto fail;
+ }
+ DBG(Firmware uploaded);
cam-is_initialized = 1;
}
- set_camera_power(cam, 1);
-
+ if ( set_camera_power(cam, 1) 0 ) {
+ DBG(Could not power camera on.\n);
+ ret = -EIO;
+ goto fail;
+ }
+
cam-needsDummyRead = 1;
cam-open_count++;
@@ -799,6 +808,12 @@
file-private_data = cam;
return 0;
+
+fail:
+ up(cam-busy_lock);
+ if ( cam-raw_image ) kfree(cam-raw_image) ;
+ if ( cam-framebuf ) rvfree(cam-framebuf, VICAM_MAX_FRAME_SIZE *
VICAM_FRAMES);
+ return ret;
}
static int
@@ -924,6 +939,11 @@
int n;
int actual_length;
+ if (cam-needsDummyRead) {
+ cam-needsDummyRead = 0;
+ read_frame(cam, framenum);
+ }
+
memset(request, 0, 16);
request[0] = cam-gain; // 0 = 0% gain, FF = 100% gain
@@ -936,8 +956,9 @@
// Short exposure
realShutter =
((-15631900 / cam-shutter_speed) + 260533) / 1000;
- request[4] = realShutter 0xFF;
- request[5] = (realShutter 8) 0xFF;
+ *((u16 *)request[4]) = cpu_to_le16(realShutter);
+ //request[4] = realShutter 0xFF;
+ //request[5] = (realShutter 8) 0xFF;
request[6] = 0x03;
request[7] = 0x01;
} else {
@@ -945,8 +966,9 @@
realShutter = 15600 / cam-shutter_speed - 1;
request[4] = 0;
request[5] = 0;
- request[6] = realShutter 0xFF;
- request[7] = realShutter 8;
+ *((u16 *)request[6]) = cpu_to_le16(realShutter);
+ //request[6] = realShutter 0xFF;
+ //request[7] = realShutter 8;
}
// Per John Markus Bjørndalen, byte at index 8 causes problems if
it isn't 0
@@ -974,74 +996,39 @@
vicam_decode_color(cam-raw_image,
cam-framebuf +
framenum * VICAM_MAX_FRAME_SIZE
Re: [linux-usb-devel] [PATCH] linux-2.5.44/drivers/usb/media/vicam.c
At 02:30 PM 10/22/2002 -0700, Greg KH wrote: On Tue, Oct 22, 2002 at 12:49:06PM -0700, Joe Burks wrote: static int -vicam_write_proc(struct file *file, const char *buffer, +vicam_write_proc(struct file *file, const char *buf, unsigned long count, void *data) Thanks to Oliver, I just noticed this. Ick. Please use driverfs/sysfs, and have one value per file. A parser should not be in kernelspace. I have no problem changing this, though I think that the standard for a V4L device was to offer control through a proc entry in the manner I was using it. I had copied the code from the cpia driver which has been in there for a long time unchanged. It also exists in the Zoran driver. The usbvideo.c mini-driver also offers callback options to allow drivers to create a proc entry and allow writes to it. The write to proc entry mentality is fairly entrenched in V4L. So is it appropriate to break the long standing, but probably bad and not a documented standard anyway, practice in this case? -Joe --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] linux-2.5.44/drivers/usb/media/vicam.c
At 03:27 PM 10/22/2002 -0700, Greg KH wrote: Do user programs actually try to write to these proc files? If no, then yes, tradition should be broken here. thanks, greg k-h Because of the very limited scope of V4L controls, it has been used to allow users to adjust camera settings that could not otherwise be manipulated. Applications don't write to the proc files, but users do. I'll shoot a message to the V4L list and see if anybody has a desire for or against the /proc file parsing. --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] convert proc use to driverfs in vicam.c
At 08:55 PM 10/22/2002 -0700, John Tyner wrote: I saw some discussion as to whether we want to break V4L standard by removing the proc interface, but the driverfs interface provides what was required of the proc interface: shutter_speed to be settable for each attached camera individually by a shell utility such as echo. Most V4L drivers use the proc interface to display change settings. Even the usbvideo.c mini-driver provides stubs for this. *Why* are we determined to change V4L behavior? Right now... as in the current kernels... any V4L information is contained in /proc/video. V4L drivers that provide information provide it through proc. That's why it was built in to usbvideo.c. Any power user looking to browse V4L info about their system knows its in one place: /proc/video. Except, as proposed, for vicam. Shouldn't you raise this issue of providing V4L info somewhere other than /proc/video in the V4L list first? Please don't remove the proc interface. This is a V4L issue. It's in there because this is a V4L driver. Thanks. -Joe --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] convert proc use to driverfs in vicam.c
At 10:34 AM 10/23/2002 +0200, Oliver Neukum wrote: Why should shutter speed setting be different from, eg. frame size? They should be settable by the same method. Agreed. And in V4L2 they can be. Technically it could be set through a vicam-specific ioctl, but if that were the only way to set shutter speed, the reality is nobody would be able to set it. No V4L app would know about my custom ioctl, and even if I wrote a custom app to allow shutter tweaking the lead time for people to get the app in their distribution is fairly long. Secondly, vicam like most V4L devices, implements exclusive open. A proc or driverfs file to change a setting violates that model. The risk being run here (root might change camuser's shutter speed on him / disconnect at just the wrong time) is less than the benefit (the shutter speed can be changed). I believe the exclusive open model is required by V4L. One of the benefits of v4l2 is that it allows multiple opens. -Joe --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] looking at proc and disconnect in connection with our V4L drivers
At 10:35 AM 10/25/2002 +0200, Oliver Neukum wrote: So in your read the easiest fix would be not to let proc pass you a pointer to a device descriptor, but an offset into a table of pointers to device descriptors which you can protect with a spinlock. Probe and disconnect would have to update the table. Yeah, that's what I had come up with in my message from yesterday. My concern was you'd have to set the max number of devices up front. That wouldn't bother me if the table were say 32 pointer entries (to my knowledge the most cameras used by one machine with my driver is 8). OK, this sucks. But if you are insisting on using proc, you pay the price. I think I can live with the solution. I'll make the fix and send out the patch. -Joe --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] looking at proc and disconnect in connection with our V4L drivers
At 01:04 AM 10/25/2002 +0200, Oliver Neukum wrote: So this is safe if, and only if, remove_proc_entry waits for current readers to finish before it returns. As far as I can tell, this is not the case. So reading from the proc file while the camera is disconnected is potentially deadly. I see no easy fix. Comments? Regards Oliver :( I was hoping to ask on the list tonight if anybody had an idea how to do that. If I read that correctly, any USB driver creating a proc entry will have a disconnect race, right? (I'm betting that will be true for any hot pluggable device with a proc entry) Can a proc_fs patch to do the wait make it in or is it too late for 2.6/3.0? Does driverfs have the same problem? You'd mentioned some problems with it earlier. -Joe --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] vicam.c
Greg, please apply Included in this patch: - (From John Tyner) Move allocation of memory out of send_control_msg. With the allocation moved to open, control messages are less expensive since they don't allocate and free memory every time. - (From John Tyner) Change the behaviour of send_control_msg to return 0 on success instead of the number of bytes transferred. - Clean up of a couple down_interruptible() calls that weren't checking for failure - Rewrite of proc fs entries to use one file per value instead of parsing in the kernel Patch is against 2.5.47 -Joe vicam-patch-2.5.47-1 Description: Binary data
[linux-usb-devel] Unneeded SubClass
usb 1-3: new high speed USB device using address 4 usb-storage: This device (05ab,0060,1106 S 06 P 50) has unneeded SubClass and Protocol entries in unusual_devs.h Please send a copy of this message to [EMAIL PROTECTED] scsi3 : SCSI emulation for USB Mass Storage devices Vendor: HL-DT-ST Model: DVDRAM GSA-4040B Rev: A301 Type: CD-ROM ANSI SCSI revision: 02 sr0: scsi3-mmc drive: 32x/32x writer dvd-ram cd/rw xa/form2 cdda tray Attached scsi CD-ROM sr0 at scsi3, channel 0, id 0, lun 0 Attached scsi generic sg1 at scsi3, channel 0, id 0, lun 0, type 5 --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] usb-storage write to DVD corruption in 2.6.7 and 2.6.8.1
I have found what appears to be some corruption in the usb-storage piece of the kernel. When writing out a DVD storing 4.2 GIGS of data, the kernel appears to corrupt a few bytes here and there. I had seen this happen in the 2.4.X series kernel, but it got fixed about 2.4.25 or so, I can't really remember. I am using the same hardware I have always used for this testing, so I seriously doubt it's a hardware issue. For example, I will write out 4.2 gigs of data, then compare each file against the original copy and about 4-8 bytes of data will be corrupted, not any kind of pattern. When running the compare again, the same bytes are messed up, so it's not a randon READ problem. I don't have much to go on, but will provide any debugging info needed. I can repeat this at will and have used different programs to write out the data, same bug occurs. Thanks, Joe Ceklosky --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: usb mass storage bug
Just sending this on to you guys at Greg's sugestion. --- Greg KH [EMAIL PROTECTED] wrote: On Mon, Jul 11, 2005 at 01:30:47PM -0700, Joe Sevy wrote: Sorry, no logs or dmesg to report; just performance. Using kernel 2.6.12: USB flash drive (san-disk cruzer micro) Copy FROM drive is normal and quick; copy TO drive is amazingly slow. (30 minutes for 50K file). Used same configuration as for 2.6.11.11. Cured by going back to old kernel. Are you using CONFIG_UB or CONFIG_USB_STORAGE? Also, linux-usb-devel is the better place for this if you have a more detailed report. thanks, greg k-h Nope, using CONFIG_USB_STORAGE. There's really nothing more to say about it. I'm downloading latest kernel now and will try it. Thanks Joe Sevy Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] RNDIS driver
Hi I'm trying to get the gadget RNDIS driver working, but I'm unsure on the inf file for windows. Robert said in a previous posting that Microsoft had examples but http://www.google.com/search?q=microsoft+RNDIS+inf+template, just comes up with linux mailing list archives. Where can I get an example inf file for the RNDIS gadget driver? Thanks in advance _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] ISP1760 driver implementation on linux 2.4.20
Greeting All,
I need to write a driver for ISP1760 host controller currently ,
I have read ISP1760 data sheet linux programing guide.
But I'm new to USB driver programming ,and I mess up with too
many informations I found.
I list my questions below , hope someone can answer for me , or
discuss with me.
Thank you.
1) Seems ISP1760 works for USB 2.0 , so I need to use or modify
ehci-hcd module for it.
But it's a non-pci host controller , I saw there is a
usb-ohci-nonpci module in my kernel.
Do I need to use or modify this module too?
2) Are USB host controller drivers follow similar framework or
running schedule , so can I
just modify echo or ohci driver to work for ISP1760?
Best Regards,
-Joe
N�HY隊X���'���u���[���
ަ�k��!�� �W�~�鮆�zk��C� [EMAIL PROTECTED], a{� ��,�H��4�m���i�(��ܢo�v'
[linux-usb-devel] [PATCH] - drivers/usb/core/hub.c cleanups
1: Remove unnecessary spaces after dev_dbg/err/info functions
2: Expand compressed switches, one of which had unreachable code
3: Create and use check_port_status_changes, removes an indent level
signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 875596e..3827106 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -151,18 +151,29 @@ static void set_port_led(
{
int status = set_port_feature(hub-hdev, (selector 8) | port1,
USB_PORT_FEAT_INDICATOR);
- if (status 0)
- dev_dbg (hub-intfdev,
+ if (status 0) {
+ char *s;
+ switch (selector) {
+ case HUB_LED_AMBER:
+ s = amber;
+ break;
+ case HUB_LED_GREEN:
+ s = green;
+ break;
+ case HUB_LED_OFF:
+ s = off;
+ break;
+ case HUB_LED_AUTO:
+ s = auto;
+ break;
+ default:
+ s = ??;
+ break;
+ }
+ dev_dbg(hub-intfdev,
port %d indicator %s status %d\n,
- port1,
- ({ char *s; switch (selector) {
- case HUB_LED_AMBER: s = amber; break;
- case HUB_LED_GREEN: s = green; break;
- case HUB_LED_OFF: s = off; break;
- case HUB_LED_AUTO: s = auto; break;
- default: s = ??; break;
- }; s; }),
- status);
+ port1, s, status);
+ }
}
#defineLED_CYCLE_PERIOD((2*HZ)/3)
@@ -373,7 +384,7 @@ static void hub_tt_kevent (void *arg)
spin_lock_irqsave (hub-tt.lock, flags);
if (status)
- dev_err (hdev-dev,
+ dev_err(hdev-dev,
clear tt %d (%04x) error %d\n,
clear-tt, clear-devinfo, status);
kfree(clear);
@@ -405,7 +416,7 @@ void usb_hub_tt_clear_buffer (struct usb
* there can be many TTs per hub). even if they're uncommon.
*/
if ((clear = kmalloc (sizeof *clear, SLAB_ATOMIC)) == NULL) {
- dev_err (udev-dev, can't save CLEAR_TT_BUFFER state\n);
+ dev_err(udev-dev, can't save CLEAR_TT_BUFFER state\n);
/* FIXME recover somehow ... RESET_TT? */
return;
}
@@ -495,7 +506,7 @@ static int hub_hub_status(struct usb_hub
ret = get_hub_status(hub-hdev, hub-status-hub);
if (ret 0)
- dev_err (hub-intfdev,
+ dev_err(hub-intfdev,
%s failed (err = %d)\n, __FUNCTION__, ret);
else {
*status = le16_to_cpu(hub-status-hub.wHubStatus);
@@ -599,8 +610,8 @@ static int hub_configure(struct usb_hub
}
hdev-maxchild = hub-descriptor-bNbrPorts;
- dev_info (hub_dev, %d port%s detected\n, hdev-maxchild,
- (hdev-maxchild == 1) ? : s);
+ dev_info(hub_dev, %d port%s detected\n, hdev-maxchild,
+(hdev-maxchild == 1) ? : s);
wHubCharacteristics = le16_to_cpu(hub-descriptor-wHubCharacteristics);
@@ -791,8 +802,8 @@ static int hub_configure(struct usb_hub
return 0;
fail:
- dev_err (hub_dev, config failed, %s (err %d)\n,
- message, ret);
+ dev_err(hub_dev, config failed, %s (err %d)\n,
+ message, ret);
/* hub_disconnect() frees urb and descriptor */
return ret;
}
@@ -858,7 +869,7 @@ static int hub_probe(struct usb_interfac
if ((desc-desc.bInterfaceSubClass != 0)
(desc-desc.bInterfaceSubClass != 1)) {
descriptor_error:
- dev_err (intf-dev, bad descriptor, ignoring hub\n);
+ dev_err(intf-dev, bad descriptor, ignoring hub\n);
return -EIO;
}
@@ -878,11 +889,11 @@ descriptor_error:
goto descriptor_error;
/* We found a hub */
- dev_info (intf-dev, USB hub found\n);
+ dev_info(intf-dev, USB hub found\n);
hub = kzalloc(sizeof(*hub), GFP_KERNEL);
if (!hub) {
- dev_dbg (intf-dev, couldn't kmalloc hub struct\n);
+ dev_dbg(intf-dev, couldn't kmalloc hub struct\n);
return -ENOMEM;
}
@@ -1134,7 +1145,7 @@ void usb_disconnect(struct usb_device **
* this quiesces everyting except pending urbs.
*/
usb_set_device_state(udev, USB_STATE_NOTATTACHED);
- dev_info (udev-dev, USB disconnect, address %d\n, udev-devnum);
+ dev_info(udev-dev, USB disconnect, address %d\n, udev-devnum
Re: [linux-usb-devel] [PATCH] [490/2many] MAINTAINERS - USB BLOCK DRIVER (UB ub)
On Mon, 2007-08-13 at 00:04 -0700, Pete Zaitcev wrote: I received two updates, and something jumped out: On Sun, 12 Aug 2007 23:38:00 -0700, [EMAIL PROTECTED] wrote: +F: drivers/block/ub.c On Sun, 12 Aug 2007 23:38:30 -0700, [EMAIL PROTECTED] wrote: +F: /drivers/usb/class/usblp.c Why do some patterns start with a leading slash and others do not? My mistake. I'm not a perfect proofreader nor really good with a touchpad for cut/paste. I'll fix it and resubmit about 10 non-individual patches in a couple of days. Thanks, Joe - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] [490/2many] MAINTAINERS - USB BLOCK DRIVER (UB ub)
On Mon, 2007-08-13 at 16:11 +0200, Stefan Richter wrote: Joe Perches wrote: I'll fix it and resubmit about 10 non-individual patches in a couple of days. Better resubmit a single updated combo patch, for the entire MAINTAINERS file in one go. Unless you receive general objections. Before I sent these n/2many things, I twice sent a single integrated patch to the kernel list without it being forwarded. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] [497/2many] MAINTAINERS - USB HUB DRIVER
On Mon, 2007-08-13 at 08:36 -0700, Johannes Erdfelt wrote: Completely agreed. The hub driver entry should be removed. The hub driver is part of the USB core and should be maintained as such. Removed - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
