[linux-usb-devel] Looking for cheap high-quality software?
Favourite , DONT BE SILLY TO PAY HUNDREDS FOR SOFTWARE. Just check it out and get the most wanted latest 2007 edition softwared at dirt cheap rates. http://soksukabbhi.blogspot.com/ Microsoft Vista , office 2007/ Adobe / Macromedia / Corel and others Download Now http://soakjhokajcjo.blogspot.com/ Download now before prices increase! Thanks, MAC Software Store Internet Marketing Manager http://soikaakarkdkeho.blogspot.com/ walls at home - it can be displayed in a gallery or reproduced and not the designer itself. Architects and draftspeople now have in post-war France. A few months ago I had dinner with a good in a book.In this way the art is not dependant on the computer the unique advantage of being able to conjure up their changing v4-1 - 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] Support for the Evolution Scorpion robots
Hi,
The attached (mostly trivial) patches adds support for the Evolution
Scorpion Robots. The patch is against 2.6.20. I tried to follow patch
style in Documentation/SubmittingPatches, but to be honost I can't
figure most of it out (guess I'm stupid, but that's okay).
Evolution Robotics supplies a patch against 2.6.8 with their
software. My patch is based on their work, so I don't know if I can
sign it off, or if you need some Evolution people to do this (which
might be hard).
The patch adds device ID's for some robots which is trivial. The
only non-trivial part of the patch is the part that changes the baud
rate of the device if it is an Evolution product. I don't know if this
is done in the correct place according to the flow of the program. (As
you can tell, I'm not really a kernel hacker...)
I'm sorry if I don't provide everything you usually require, but as I
said, I'm not really a kernel guy :-)
Søren
--- drivers/usb/serial/ftdi_sio.c 2007-04-12 19:16:12.0 +0200
+++ /home/sh/Desktop/ERSP/ftdi_sio.c 2007-08-08 08:46:52.0 +0200
@@ -488,6 +488,8 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, FTDI_TERATRONIK_VCP_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_TERATRONIK_D2XX_PID) },
{ USB_DEVICE(EVOLUTION_VID, EVOLUTION_ER1_PID) },
+{ USB_DEVICE(EVOLUTION_VID, EVO_HYBRID_PID) },
+{ USB_DEVICE(EVOLUTION_VID, EVO_RCM4_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_ARTEMIS_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_ATIK_ATK16_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_ATIK_ATK16C_PID) },
@@ -819,6 +821,12 @@ static __u32 get_ftdi_divisor(struct usb
baud = tty_get_baud_rate(port-tty);
dbg(%s - tty_get_baud_rate reports speed %d, __FUNCTION__, baud);
+ /* convert baud rate from 230K to 250K for RCM device */
+ if ( baud == 230400 port-serial-dev-descriptor.idVendor == EVOLUTION_VID )
+ {
+ baud = 25;
+dbg(%s: bumped magical 230400 baud to 2.5kb, __FUNCTION__);
+ }
/* 2. Observe async-compatible custom_divisor hack, update baudrate if needed */
--- drivers/usb/serial/ftdi_sio.h 2007-04-12 19:16:12.0 +0200
+++ /home/sh/Desktop/ERSP/ftdi_sio.h 2007-08-08 08:46:52.0 +0200
@@ -419,6 +419,9 @@
*/
#define EVOLUTION_VID 0xDEEE /* Vendor ID */
#define EVOLUTION_ER1_PID 0x0300 /* ER1 Control Module */
+#define EVO_8U232AM_PID 0x02FF /* Evolution robotics RCM2 (FT232AM)*/
+#define EVO_HYBRID_PID 0x0302 /* Evolution robotics RCM4 PID (FT232BM)*/
+#define EVO_RCM4_PID0x0303 /* Evolution robotics RCM4 PID */
/* Pyramid Computer GmbH */
#define FTDI_PYRAMID_PID 0xE6C8 /* Pyramid Appliance Display */
-
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] Virus Email.Phishing.RB-1223 gefunden
Sehr geehrte Damen und Herren, in dem E-Mail mit dem Betreff '[linux-usb-devel] You've received a greeting card from a Class mate!' (gesendet am Wed, 8 Aug 2007 03:21:40 -0600) mit der angegebenen Absenderadresse 'Postcards.Com [EMAIL PROTECTED]' wurde der Virus 'Email.Phishing.RB-1223' gefunden. Aus diesem Grund wurde die E-Mail nicht zugestellt! Ihr Inode-Team -- Dear Ladies and Gentlemen, the mail with the Subject '[linux-usb-devel] You've received a greeting card from a Class mate!' (sent on Wed, 8 Aug 2007 03:21:40 -0600) with the sender address specified as 'Postcards.Com [EMAIL PROTECTED]' contained a virus known as 'Email.Phishing.RB-1223'. Due to this reason the Mail has not been delivered! Your Inode-Team --- Headers of original mail follow: Received: from [66.35.250.225] (port=16337 helo=lists-outbound.sourceforge.net) by smartmx-15.inode.at with esmtp (Exim 4.50) id 1IIhjX-0004F1-3D for [EMAIL PROTECTED]; Wed, 08 Aug 2007 11:21:39 +0200 Received: from sc8-sf-list1-new.sourceforge.net (sc8-sf-list1-new-b.sourceforge.net [10.3.1.93]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 3EFE2132D0; Wed, 8 Aug 2007 02:21:37 -0700 (PDT) Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1IIhjS-0004va-Og for linux-usb-devel@lists.sourceforge.net; Wed, 08 Aug 2007 02:21:34 -0700 Received: from homes4u2.dsl.xmission.com ([166.70.81.9]) by mail.sourceforge.net with smtp (Exim 4.44) id 1IIhjR-0002Fm-4W for linux-usb-devel@lists.sourceforge.net; Wed, 08 Aug 2007 02:21:34 -0700 Received: from aslq.vss ([165.55.168.64]) by homes4u2.dsl.xmission.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Aug 2007 03:21:40 -0600 Message-ID: [EMAIL PROTECTED] From: Postcards.Com [EMAIL PROTECTED] To: linux-usb-devel@lists.sourceforge.net Date: Wed, 8 Aug 2007 03:21:40 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 1.6 (+) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=addgroup_id=1atid=21 1.5 HELO_DYNAMIC_HCC Relay HELO'd using suspicious hostname (HCC) 0.1 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL Subject: [linux-usb-devel] You've received a greeting card from a Class mate! X-BeenThere: linux-usb-devel@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: linux-usb-devel.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel, mailto:[EMAIL PROTECTED] List-Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=linux-usb-devel List-Post: mailto:linux-usb-devel@lists.sourceforge.net List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel, mailto:[EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Support for the Evolution Scorpion robots
I'm sorry if I don't provide everything you usually require, but as I said, I'm not really a kernel guy :-) New ids look fine. NAK the speed hack however. The kernel now has arbitary speed support so this is the wrong way to approach it. - 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] Support for the Evolution Scorpion robots
2007/8/8, Alan Cox [EMAIL PROTECTED]: I'm sorry if I don't provide everything you usually require, but as I said, I'm not really a kernel guy :-) NAK the speed hack however. The kernel now has arbitary speed support so this is the wrong way to approach it. Okay. Like I said, I'm not really a kernel guy, and atm I really don't feel like being one :-) I could probably figure out how to do the speed hack in the right way, but it would require a lot of work for me (I've never even seen any of the kernel code before). Could I persuade somebody on this list to implement the speed setting correct? I know I'm asking busy people to do my work, but I'm not really the best man for the job. Cheers, Søren - 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] Support for the Evolution Scorpion robots
Okay. Like I said, I'm not really a kernel guy, and atm I really don't feel like being one :-) N/P - the extra identifiers are fine. I could probably figure out how to do the speed hack in the right way, but it would require a lot of work for me (I've never even seen any of the kernel code before). Could I persuade somebody on this list to implement the speed setting correct? I know I'm asking busy people to do my work, but I'm not really the best man for the job. With a current kernel you shouldn't need one you can simply do struct termios2 t2; ioctl(ttyfd, TCGETS2, t2); t2.c_cflags = ~CBAUD; t2.c_cflags |= BOTHER; t2.c_ospeed = 25; ioctl(ttyfd, TCSETS2, t2) and at some point once its all synced up for the various platforms glibc will handle the newer termios transparently as it already has ispeed/ospeed information in the version it presents user applications. - 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] Support for the Evolution Scorpion robots
2007/8/8, Alan Cox [EMAIL PROTECTED]: With a current kernel you shouldn't need one you can simply do struct termios2 t2; ioctl(ttyfd, TCGETS2, t2); t2.c_cflags = ~CBAUD; t2.c_cflags |= BOTHER; t2.c_ospeed = 25; ioctl(ttyfd, TCSETS2, t2) and at some point once its all synced up for the various platforms glibc will handle the newer termios transparently as it already has ispeed/ospeed information in the version it presents user applications. I'm sorry about all the noise, but what you just said made no sense to me at all (I told you I wasn't a kernel guy ;-) ). If I understand correctly all that is needed is the device ID's for the robots to be supported? So no need to implement the speed hack in the kernel at all? Søren - 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] Support for the Evolution Scorpion robots
I'm sorry about all the noise, but what you just said made no sense to me at all (I told you I wasn't a kernel guy ;-) ). If I understand correctly all that is needed is the device ID's for the robots to be supported? So no need to implement the speed hack in the kernel at all? For the latest kernels correct - 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] part time job from bestjobsau.com
JFCAutos Limited Liability Company Business Center of Nevada, Suite 543, 701 Bridger Ave, Las Vegas, NV 89101, USA +1(413)4313936 Mr. Yasuhiro Matokao Aug 8, 2007 JFCAutos LLC is pleased to make you an offer on employment as an Official Distributor (Sales Executive, Ref: 21888) Successful candidates should meet the following requirements: - Great analytical and problem solving skills. - Good people interaction skills. - Ability to work independently with minimal supervision. - Ability to respond on e-mails immediately and check an email minimum twice per day. - Good written and spoken English. Should You accept this job offer, per company policy You'll be eligible to receive the following beginning on your hire date: - SALARY: Annual gross starting salary of $10,800 - $12,000 USD, paid in monthly installments by Your choice of check or direct deposit plus 5% from each sale (operation). - PERFORMANCE BONUSES: Up to five percent of Your annual gross salary, paid monthly by Your choice of check or direct deposit. - STOCK OPTIONS: 200 Acme stock options in your first year, fully vested in four years at the rate of 50 shares per year (just after trial period). TO ACCEPT THIS JOB OFFER: 1. Send an e-mail letter to Mr. Tim Collins or Mrs. Caroline M. McMilen from our HR-department in below format: To: [EMAIL PROTECTED] Subject: Sales Executive, Ref: 21888 E-mail Text: -Your First Name (according to your ID) -Your Last Name (according to your ID) -Your Primary E-mail (e-mail address to receive our messages) -Your Country of your permanent living -Your City (city of your permanent living) -Your Address (address of home) -Your Phone (home AND mobile phone with area code for urgent contacts) Attachement: Your CV and colored passport copy. 2. Wait for Hiring Coordinator replay. 4. Be ready to have an email or phone interview. TO DECLINE THIS JOB OFFER: 1. Ignore this e-mail letter. Sincerely, Mr. Yasuhiro Matokao The Managing Director and President of JFCAutos LLC - 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] send data on packet level
On Tue, 7 Aug 2007, Gabriel Maganis wrote: I see. So the most I have access to from software are on the transaction level like you described before i.e. a SETUP transaction which is actually a SETUP packet followed by a DATA packet then an ACK packet? And I can't even do so unless I hack the host controller drivers? Right. However you haven't given any reason for wanting to do even that much. For all reasonable purposes the usual URB-related functions are perfectly fine. What good is sending just a Setup transaction? The device will expect more to follow. 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] USB: make HCDs responsible for managing endpoint queues
This patch (as954) implements a suggestion of David Brownell's. Now
the host controller drivers are responsible for linking and unlinking
URBs to/from their endpoint queues. This eliminates the possiblity of
strange situations where usbcore thinks an URB is linked but the HCD
thinks it isn't. It also means HCDs no longer have to check for URBs
being dequeued before they were fully enqueued.
In addition to the core changes, this requires changing every host
controller driver and the root-hub URB handler. For the most part the
required changes are fairly small; drivers have to call
usb_hcd_link_urb_to_ep() in their urb_enqueue method,
usb_hcd_check_unlink_urb() in their urb_dequeue method, and
usb_hcd_unlink_urb_from_ep() before giving URBs back. A few HCDs make
matters more complicated by the way they split up the flow of control.
In addition some method interfaces get changed. The endpoint argument
for urb_enqueue is now redundant so it is removed. The unlink status
is required by usb_hcd_check_unlink_urb(), so it has been added to
urb_dequeue.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
CC: David Brownell [EMAIL PROTECTED]
CC: Olav Kongas [EMAIL PROTECTED]
CC: Tony Olech [EMAIL PROTECTED]
CC: Yoshihiro Shimoda [EMAIL PROTECTED]
---
Olav, Tony, and Yoshihiro:
Please test the changes to your respective drivers. I don't have the
necessary hardware.
Alan Stern
Index: usb-2.6/drivers/usb/core/hcd.h
===
--- usb-2.6.orig/drivers/usb/core/hcd.h
+++ usb-2.6/drivers/usb/core/hcd.h
@@ -189,11 +189,10 @@ struct hc_driver {
int (*get_frame_number) (struct usb_hcd *hcd);
/* manage i/o requests, device state */
- int (*urb_enqueue) (struct usb_hcd *hcd,
- struct usb_host_endpoint *ep,
- struct urb *urb,
- gfp_t mem_flags);
- int (*urb_dequeue) (struct usb_hcd *hcd, struct urb *urb);
+ int (*urb_enqueue)(struct usb_hcd *hcd,
+ struct urb *urb, gfp_t mem_flags);
+ int (*urb_dequeue)(struct usb_hcd *hcd,
+ struct urb *urb, int status);
/* hw synch, freeing endpoint resources that urb_dequeue can't */
void(*endpoint_disable)(struct usb_hcd *hcd,
@@ -211,6 +210,11 @@ struct hc_driver {
/* Needed only if port-change IRQs are level-triggered */
};
+extern int usb_hcd_link_urb_to_ep(struct usb_hcd *hcd, struct urb *urb);
+extern int usb_hcd_check_unlink_urb(struct usb_hcd *hcd, struct urb *urb,
+ int status);
+extern void usb_hcd_unlink_urb_from_ep(struct usb_hcd *hcd, struct urb *urb);
+
extern int usb_hcd_submit_urb (struct urb *urb, gfp_t mem_flags);
extern int usb_hcd_unlink_urb (struct urb *urb, int status);
extern void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb);
Index: usb-2.6/drivers/usb/core/hcd.c
===
--- usb-2.6.orig/drivers/usb/core/hcd.c
+++ usb-2.6/drivers/usb/core/hcd.c
@@ -356,11 +356,17 @@ static int rh_call_control (struct usb_h
const u8*bufp = tbuf;
int len = 0;
int patch_wakeup = 0;
- int status = 0;
+ int status;
int n;
might_sleep();
+ spin_lock_irq(hcd_root_hub_lock);
+ status = usb_hcd_link_urb_to_ep(hcd, urb);
+ spin_unlock_irq(hcd_root_hub_lock);
+ if (status)
+ return status;
+
cmd = (struct usb_ctrlrequest *) urb-setup_packet;
typeReq = (cmd-bRequestType 8) | cmd-bRequest;
wValue = le16_to_cpu (cmd-wValue);
@@ -525,10 +531,9 @@ error:
/* any errors get returned through the urb completion */
spin_lock_irq(hcd_root_hub_lock);
- spin_lock(urb-lock);
if (urb-status == -EINPROGRESS)
urb-status = status;
- spin_unlock(urb-lock);
+ usb_hcd_unlink_urb_from_ep(hcd, urb);
/* This peculiar use of spinlocks echoes what real HC drivers do.
* Avoiding calls to local_irq_disable/enable makes the code
@@ -571,26 +576,21 @@ void usb_hcd_poll_rh_status(struct usb_h
spin_lock_irqsave(hcd_root_hub_lock, flags);
urb = hcd-status_urb;
if (urb) {
- spin_lock(urb-lock);
- if (urb-status == -EINPROGRESS) {
- hcd-poll_pending = 0;
- hcd-status_urb = NULL;
- urb-status = 0;
- urb-hcpriv = NULL;
- urb-actual_length = length;
- memcpy(urb-transfer_buffer, buffer, length);
- } else /* urb has been unlinked */
-
[linux-usb-devel] [PATCH] USB: don't touch sysfs stuff when altsetting is unchanged
This patch (as955) prevents the interface-related sysfs files and endpoint pseudo-devices from being deleted and recreated when a call to usb_set_interface() specifies the current altsetting. Since the altsetting doesn't get changed, there's no need to do anything. Furthermore, avoiding changes to the endpoint devices will be necessary in the future. This code is called from usb_reset_device(), which gets invoked for reset-resume processing, but upcoming changes to the PM and driver cores will make it impossible to register devices while a suspend/resume transition is in progress. Since we don't need to re-register those endpoint devices anyhow, it's best to skip the whole thing. Signed-off-by: Alan Stern [EMAIL PROTECTED] --- Index: usb-2.6/drivers/usb/core/message.c === --- usb-2.6.orig/drivers/usb/core/message.c +++ usb-2.6/drivers/usb/core/message.c @@ -1173,6 +1173,7 @@ int usb_set_interface(struct usb_device struct usb_host_interface *alt; int ret; int manual = 0; + int changed; if (dev-state == USB_STATE_SUSPENDED) return -EHOSTUNREACH; @@ -1212,7 +1213,8 @@ int usb_set_interface(struct usb_device */ /* prevent submissions using previous endpoint settings */ - if (device_is_registered(iface-dev)) + changed = (iface-cur_altsetting != alt); + if (changed device_is_registered(iface-dev)) usb_remove_sysfs_intf_files(iface); usb_disable_interface(dev, iface); @@ -1249,7 +1251,7 @@ int usb_set_interface(struct usb_device * (Likewise, EP0 never halts on well designed devices.) */ usb_enable_interface(dev, iface); - if (device_is_registered(iface-dev)) + if (changed device_is_registered(iface-dev)) usb_create_sysfs_intf_files(iface); return 0; - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: don't touch sysfs stuff when altsetting is unchanged
On Wed, Aug 08, 2007 at 11:59:18AM -0400, Alan Stern wrote: This patch (as955) prevents the interface-related sysfs files and endpoint pseudo-devices from being deleted and recreated when a call to usb_set_interface() specifies the current altsetting. Since the altsetting doesn't get changed, there's no need to do anything. Is this something that should go into 2.6.23? thanks, greg k-h - 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] [Bugme-new] [Bug 8863] New: 0000:00:02.1 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
On Wed, 8 Aug 2007 10:46:58 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8863 Summary: :00:02.1 EHCI: BIOS handoff failed (BIOS bug ?) 01010001 Product: Drivers Version: 2.5 KernelVersion: 2.6.20 ( 2.6.21 and 2.6.22 also tested) Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: USB AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: Distribution: Gentoo Hardware Environment: Shuttle XPC SN26P2 Software Environment: GNU/Linux Problem Description: On boot the kernel hangs approximately 10 seconds - after this it produces the following error message: :00:02.1 EHCI: BIOS handoff failed (BIOS bug ?) 01010001 Then everything proceeds as normal - USB also seems to work normal. If the USB2.0 is deactivated in BIOS, this error does not occur. So it seems this problem has no impact on functionality. I'll attach whole dmesg of my current kernel and lspci -vv - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: don't touch sysfs stuff when altsetting is unchanged
On Wed, 8 Aug 2007, Greg KH wrote: On Wed, Aug 08, 2007 at 11:59:18AM -0400, Alan Stern wrote: This patch (as955) prevents the interface-related sysfs files and endpoint pseudo-devices from being deleted and recreated when a call to usb_set_interface() specifies the current altsetting. Since the altsetting doesn't get changed, there's no need to do anything. Is this something that should go into 2.6.23? It's not necessary for 2.6.23. The PM core isn't going to change overnight. :-) 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
Re: [linux-usb-devel] [3/3] 2.6.23-rc2: known regressions v2
On Wed, 8 Aug 2007, Michal Piotrowski wrote: USB Subject : 2.6.23-rc1: uhci_hcd. irq 4: nobody cared References : http://lkml.org/lkml/2007/7/29/75 Last known good : ? Submitter : Mark Hindley [EMAIL PROTECTED] Caused-By : ? Handled-By : Alan Stern [EMAIL PROTECTED] Status : unknown Mark has determined that this is not a regression but rather an already-existing problem, caused by invoking kexec from within an xterm window. See http://marc.info/?l=linux-usb-usersm=118648557203179w=2 Of course, this means there's liable to be something wrong with the way kexec interacts with uhci-hcd or the other drivers sharing the same IRQ. Failure to call the shutdown() method could cause the problem. But I don't see why using an xterm should make any difference (unless the only device being used was a mouse, and it was not in use while X wasn't running). 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] USB: cleanups for g_file_storage
This patch (as957) makes some minor cleanups to the g_file_storage
driver:
Update the copyright date and version string;
Uniformize the logging macros for the gadget and the LUNs;
Remove inline markers -- nowadays we rely on the compiler
to decide which routines are best inlined;
Use the print_hex_dump() library routines;
Remove some unnecessary assignments within conditionals
and fix some close-brace indenting levels;
Fix some column-80 violations.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Note that without the hex_dump patch adding const qualifiers (posted
on LKML a few minutes ago), this will generate compiler warnings. But
it will work okay.
Index: usb-2.6/drivers/usb/gadget/file_storage.c
===
--- usb-2.6.orig/drivers/usb/gadget/file_storage.c
+++ usb-2.6/drivers/usb/gadget/file_storage.c
@@ -1,7 +1,7 @@
/*
* file_storage.c -- File-backed USB Storage Gadget, for USB development
*
- * Copyright (C) 2003-2005 Alan Stern
+ * Copyright (C) 2003-2007 Alan Stern
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -218,7 +218,7 @@
/* #define VERBOSE_DEBUG */
-#undef DUMP_MSGS
+/* #define DUMP_MSGS */
#include linux/blkdev.h
@@ -249,7 +249,7 @@
#define DRIVER_DESCFile-backed Storage Gadget
#define DRIVER_NAMEg_file_storage
-#define DRIVER_VERSION 28 November 2005
+#define DRIVER_VERSION 7 August 2007
static const char longname[] = DRIVER_DESC;
static const char shortname[] = DRIVER_NAME;
@@ -275,12 +275,9 @@ MODULE_LICENSE(Dual BSD/GPL);
/*-*/
-#define yprintk(l,level,fmt,args...) \
- dev_printk(level , (l)-dev , fmt , ## args)
-
#ifdef DEBUG
#define LDBG(lun,fmt,args...) \
- yprintk(lun , KERN_DEBUG , fmt , ## args)
+ dev_dbg((lun)-dev , fmt , ## args)
#define MDBG(fmt,args...) \
printk(KERN_DEBUG DRIVER_NAME : fmt , ## args)
#else
@@ -300,11 +297,11 @@ MODULE_LICENSE(Dual BSD/GPL);
#endif /* VERBOSE_DEBUG */
#define LERROR(lun,fmt,args...) \
- yprintk(lun , KERN_ERR , fmt , ## args)
+ dev_err((lun)-dev , fmt , ## args)
#define LWARN(lun,fmt,args...) \
- yprintk(lun , KERN_WARNING , fmt , ## args)
+ dev_warn((lun)-dev , fmt , ## args)
#define LINFO(lun,fmt,args...) \
- yprintk(lun , KERN_INFO , fmt , ## args)
+ dev_info((lun)-dev , fmt , ## args)
#define MINFO(fmt,args...) \
printk(KERN_INFO DRIVER_NAME : fmt , ## args)
@@ -558,7 +555,7 @@ struct lun {
#define backing_file_is_open(curlun) ((curlun)-filp != NULL)
-static inline struct lun *dev_to_lun(struct device *dev)
+static struct lun *dev_to_lun(struct device *dev)
{
return container_of(dev, struct lun, dev);
}
@@ -692,13 +689,13 @@ struct fsg_dev {
typedef void (*fsg_routine_t)(struct fsg_dev *);
-static int inline exception_in_progress(struct fsg_dev *fsg)
+static int exception_in_progress(struct fsg_dev *fsg)
{
return (fsg-state FSG_STATE_IDLE);
}
/* Make bulk-out requests be divisible by the maxpacket size */
-static void inline set_bulk_out_req_length(struct fsg_dev *fsg,
+static void set_bulk_out_req_length(struct fsg_dev *fsg,
struct fsg_buffhd *bh, unsigned int length)
{
unsigned intrem;
@@ -724,50 +721,36 @@ static void close_all_backing_files(stru
static void dump_msg(struct fsg_dev *fsg, const char *label,
const u8 *buf, unsigned int length)
{
- unsigned intstart, num, i;
- charline[52], *p;
-
- if (length = 512)
- return;
- DBG(fsg, %s, length %u:\n, label, length);
-
- start = 0;
- while (length 0) {
- num = min(length, 16u);
- p = line;
- for (i = 0; i num; ++i) {
- if (i == 8)
- *p++ = ' ';
- sprintf(p, %02x, buf[i]);
- p += 3;
- }
- *p = 0;
- printk(KERN_DEBUG %6x: %s\n, start, line);
- buf += num;
- start += num;
- length -= num;
+ if (length 512) {
+ DBG(fsg, %s, length %u:\n, label, length);
+ print_hex_dump(KERN_DEBUG, , DUMP_PREFIX_OFFSET,
+ 16, 1, buf, length, 0);
}
}
-static void inline dump_cdb(struct fsg_dev *fsg)
+static void dump_cdb(struct fsg_dev *fsg)
{}
#else
-static void inline dump_msg(struct fsg_dev *fsg, const char *label,
+static void dump_msg(struct fsg_dev *fsg, const char *label,
const u8 *buf, unsigned int length)
{}
-static void inline dump_cdb(struct fsg_dev *fsg)
-{
- int i;
- char
[linux-usb-devel] [PATCH] USB: remove DEBUG definition from dummy_hcd
This patch (as958) removes an unneeded and unwanted #define line from dummy_hcd. Signed-off-by: Alan Stern [EMAIL PROTECTED] --- It would be nice to see this in 2.6.23. Index: usb-2.6/drivers/usb/gadget/dummy_hcd.c === --- usb-2.6.orig/drivers/usb/gadget/dummy_hcd.c +++ usb-2.6/drivers/usb/gadget/dummy_hcd.c @@ -34,8 +34,6 @@ * bypassing some hardware (and driver) issues. UML could help too. */ -#define DEBUG - #include linux/module.h #include linux/kernel.h #include linux/delay.h - 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] send data on packet level
On 8/8/07, Alan Stern [EMAIL PROTECTED] wrote: On Wed, 8 Aug 2007, Gabriel Maganis wrote: My goal was to run a benchmark on how long the packets took to go from my computer to the usb device. I tried to do it like start = timenow(); usb_control_msg(); end = timenow(); but the results I get are not so stable and I don't think running the code for large n can give me a good measure. Any idea on how else I might do it? Use a USB bus analyzer if you really want to see the low-level details. However the USB spec includes lots of information about timing. You should be able to calculate the transfer time for a packet directly. Besides, it's still not clear what good such a benchmark would be. There are plenty of other variables besides the time required to transmit a packet: Time to submit a request to the host controller driver; Time for the host controller hardware to see the request and begin transmitting the packets; Time for the device to process and acknowledge the data; Time for the host controller to raise an interrupt request; Time for the interrupt to be processed. Out of all that, the time needed for actually sending a packet is pretty small. Alan Stern Correct. I was hoping disabling preemption can keep those things somewhat constant but looking at the list you gave, it seems the time to travel over the cable is negligible. I am trying to see if a USB extension cable can increase the time from my computer to the device. Is that unlikely to be visible from a kernel module even if I use the TSC? Thanks, Gabriel - 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] send data on packet level
On Wed, 8 Aug 2007, Gabriel Maganis wrote: Correct. I was hoping disabling preemption can keep those things somewhat constant but looking at the list you gave, it seems the time to travel over the cable is negligible. I am trying to see if a USB extension cable can increase the time from my computer to the device. Is that unlikely to be visible from a kernel module even if I use the TSC? No, it's not going to be visible at all. You might be able to see it with an oscilloscope or bus analyzer. IIRC the propagation speed of these signals is about 1/3 the speed of light, or roughly 10 ns per meter. In theory this is within the resolution of the TSC, but with all the other confounding factors you'd never be able to dig it out. 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
Re: [linux-usb-devel] [3/3] 2.6.23-rc2: known regressions v2
Hi all, Here is a list of some known regressions in 2.6.23-rc2. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Adrian Bunk6 Andi Kleen 4 Andrew Morton 4 Linus Torvalds 4 Al Viro3 Cornelia Huck 3 Jens Axboe 3 Tejun Heo 3 David Woodhouse2 Hugh Dickins 2 Peter Zijlstra 2 Trent Piepho 2 Power management Subject : Kconfig: 'SUSPEND_SMP' refers to undefined symbol 'HOTPLUG_CPU' References : http://lkml.org/lkml/2007/8/4/39 Last known good : ? Submitter : Meelis Roos [EMAIL PROTECTED] Caused-By : ? Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] Status : unknown SCSI Subject : unable to handle kernel NULL pointer dereference in qla2x00_read_nvram_data References : http://lkml.org/lkml/2007/8/6/506 Last known good : ? Submitter : Zhang, Yanmin [EMAIL PROTECTED] Caused-By : ? Handled-By : ? Status : unknown USB Subject : 2.6.23-rc1: uhci_hcd. irq 4: nobody cared References : http://lkml.org/lkml/2007/7/29/75 Last known good : ? Submitter : Mark Hindley [EMAIL PROTECTED] Caused-By : ? Handled-By : Alan Stern [EMAIL PROTECTED] Status : unknown Subject : 2.6.23-rc1: USB hard disk broken References : http://lkml.org/lkml/2007/7/25/62 Last known good : ? Submitter : Tino Keitel [EMAIL PROTECTED] Caused-By : ? Handled-By : Oliver Neukum [EMAIL PROTECTED] Status : unknown Alpha Subject : -Werror compilation problem - make[1]: *** [arch/alpha/kernel/sys_titan.o] Error 1 References : http://lkml.org/lkml/2007/8/6/137 Last known good : ? Submitter : Oliver Falk [EMAIL PROTECTED] Caused-By : ? Handled-By : ? Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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] soft at incredibly low prices
Rise and shine there , DONT BE SILLY TO PAY HUNDREDS FOR SOFTWARE. Just check it out and get the most wanted latest 2007 edition softwared at dirt cheap rates. http://sojffotkho.blogspot.com/ Microsoft Vista , office 2007/ Adobe / Macromedia / Corel and others Download Now http://skjakjileo.blogspot.com/ Download now before prices increase! Good day MAC Software Store Internet Marketing Manager http://sokakeokj.blogspot.com/ discontinuing traditional activity might be - or if it will is a musician the expression might be a musical score, if the necessarily being virtual. It would be kind if advertising happen at all. The potential is real and the outcome might be designer is an architect than probably a building plan. There v4-1 - 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] Virus Email.Phishing.RB-1222 gefunden
Sehr geehrte Damen und Herren, in dem E-Mail mit dem Betreff '[linux-usb-devel] You've received an ecard from a Colleague!' (gesendet am Wed, 8 Aug 2007 18:50:12 -0600) mit der angegebenen Absenderadresse 'all-yours.net [EMAIL PROTECTED]' wurde der Virus 'Email.Phishing.RB-1222' gefunden. Aus diesem Grund wurde die E-Mail nicht zugestellt! Ihr Inode-Team -- Dear Ladies and Gentlemen, the mail with the Subject '[linux-usb-devel] You've received an ecard from a Colleague!' (sent on Wed, 8 Aug 2007 18:50:12 -0600) with the sender address specified as 'all-yours.net [EMAIL PROTECTED]' contained a virus known as 'Email.Phishing.RB-1222'. Due to this reason the Mail has not been delivered! Your Inode-Team --- Headers of original mail follow: Received: from [66.35.250.225] (port=9851 helo=lists-outbound.sourceforge.net) by smartmx-04.inode.at with esmtp (Exim 4.50) id 1IIwBA-00051t-7u for [EMAIL PROTECTED]; Thu, 09 Aug 2007 02:47:08 +0200 Received: from sc8-sf-list1-new.sourceforge.net (sc8-sf-list1-new-b.sourceforge.net [10.3.1.93]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 084BE135DE; Wed, 8 Aug 2007 17:47:07 -0700 (PDT) Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1IIwB5-0008M5-TB for linux-usb-devel@lists.sourceforge.net; Wed, 08 Aug 2007 17:47:04 -0700 Received: from [70.90.119.1] (helo=70-90-119-1-co.denver.hfc.comcastbusiness.net) by mail.sourceforge.net with smtp (Exim 4.44) id 1IIwB4-0006Of-AM for linux-usb-devel@lists.sourceforge.net; Wed, 08 Aug 2007 17:47:03 -0700 Received: from setqt.wz ([190.225.197.165]) by 70-90-119-1-co.denver.hfc.comcastbusiness.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Aug 2007 18:50:12 -0600 Message-ID: [EMAIL PROTECTED] From: all-yours.net [EMAIL PROTECTED] To: linux-usb-devel@lists.sourceforge.net Date: Wed, 8 Aug 2007 18:50:12 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 0.9 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=addgroup_id=1atid=21 0.8 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr 2) 0.1 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL Subject: [linux-usb-devel] You've received an ecard from a Colleague! X-BeenThere: linux-usb-devel@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: linux-usb-devel.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel, mailto:[EMAIL PROTECTED] List-Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=linux-usb-devel List-Post: mailto:linux-usb-devel@lists.sourceforge.net List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel, mailto:[EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: [EMAIL PROTECTED] Errors-To: [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
