[linux-usb-devel] 咨询报价
致财务/经理： 您好！ 公司有渠道可为你代开普通销售，增值税，餐饮，运输，其他服务发票。凡是我公司开出的发票皆是正规发票。 可让贵公司验证后再付款！（公司领出的发票税局皆有备案，您可放心与我们合作。） 普通销售发票只收2%点！让我们共赴双赢之路！ 联系人：华小姐 电话: 13928499867 您会有需要发票的时候。 (请保留手机号码) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ 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] device not accepting address
hi, I am using 2.6.11 kernel patched with 2.6.12 patches for usb. USB device is host-host cable from prolific (product=0x2501, vendor=0x063) The demsg output along with the prints on minicom: usb 1-2: device descriptor read/64, error -110 usb 1-2: new full speed USB device using s3c2410-ohci and address 35 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 usb 1-2: new full speed USB device using s3c2410-ohci and address 36 / # / # / # usb 1-2: device not accepting address 36, error -110 / # usb 1-2: new full speed USB device using s3c2410-ohci and address 37 / # / # / # usb 1-2: device not accepting address 37, error -110 / # / # / # / # / # / # / # / # / # dmesg usb 1-2: new full speed USB device using s3c2410-ohci and address 38 uting cache hash table of 512 buckets, 4Kbytes TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) NET: Registered protocol family 17 Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. fill_kobj_path: path = '/block/mtdblock3' VFS: Mounted root (cramfs filesystem) readonly. Mounted devfs on /dev Freeing init memory: 112K selected clock c02035a8 (pclk) quot 26, calc 115277 usb 1-2: new full speed USB device using s3c2410-ohci and address 2 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 3 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 4 usb 1-2: device not accepting address 4, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 5 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 usb 1-2: device not accepting address 5, error -110 kobject NULL: cleaning up usb 1-2usb 1-2: device descriptor read/64, error -110 : new full speed USB device using s3c2410-ohci and address 6 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 7 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 8 usb 1-2: device not accepting address 8, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 9 usb 1-2: device not accepting address 9, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 10 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 11 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 12 usb 1-2: device not accepting address 12, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 13 usb 1-2: device not accepting address 13, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 14 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 15 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 16 usb 1-2: device not accepting address 16, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 17 usb 1-2: device not accepting address 17, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device usinusb 1-2: device descriptor read/64, error -110 g s3c2410-ohci and address 18 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 19 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 20 usb 1-2: device not accepting address 20, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 21 usb 1-2: device not accepting address 21, error -110 kobject NULL: cleaning up usb 1-2: new full speed USB device using s3c2410-ohci and address 22 usb 1-2: device descriptor read/64, error -110 usb 1-2: device
[linux-usb-devel] [QUESTION] HCD's suspend implementation
Hi, I'm looking at the USB suspend code of kernel 2.6.15-rc5. It seems that it has changed a lot since 2.6.14, and I'm quite confused on how to implement the suspend feature for a HCD. Actually the hcd can be suspended itself (driver suspend) or it can be asked to suspend the bus through its root hub. For the first case (driver suspend), does the HCD need to suspend the bus ? Another question regarding root hub. Does it need to support SET_FEATURE PORT_SUSPEND request ? I don't think so because usb core seems to call hcd-bus_suspend to achieve that... Well, I'm asking these questions because the way sl811 and isp116 implement suspend are different... Thanks -- Franck --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=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] question about new usb-skeleton.c code
Hello, I maintain a 2.4 USB driver based off an old version of usb-skeleton.c. (It's for an in-house tester used where I work, and the choice of kernel version is out of my hands.) I've just taken a look at the latest (2.6) version of usb-skeleton.c, and I'm wondering if someone would be generous enough to explain to me how a part of it works. It's the writes I'm wondering about. It appears that the code allocates a new URB and buffer for each write. Once the write is completed, the associated URB and buffer are freed. But one of the ways I benchmark our download speeds is by filling a 4K buffer with valid packets and looping over a single write(2) call. With the CPU being so much faster than USB and an URB/buffer pair being allocated for each write, it would seem like it wouldn't be long before an -ENOMEM was returned. Of course, one answer would be, Don't do that! But with a sizable number of testers connected to the same host, I could see the result being the same, or similar, even during normal usage. What am I missing? Thanks, Sam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ 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] Problem with usb-serial layer
On Wed, Dec 14, 2005 at 05:16:13PM -0800, Ajay Jain wrote: Greg KH wrote: On Wed, Dec 14, 2005 at 02:30:46PM -0800, Ajay Jain wrote: Hi, I am doing bulk out transfers using my own usb host-controller driver on linux 2.4.21. The device being used is a usb-serial device of type pl203. I sometimes see that I get all packets of size zero for a bulk out transfer, after an initial valid size. I complete the first bulk transfer successfully, but after that I do not get any non-zero byte packet to be transferred. Any clues? Does the same thing happen for other types of usb devices with your host controller driver? Have a pointer to your drive anywhere? thanks, greg k-h Have checked for interrupt (kb/mouse) xactions. They work perfectly fine. USB-Serial is my first bulk experiment. Actually, when I remove some prints from the code, the upper layer starts giving 0 bytes packet after the first one. When there are certain debug messages in the hcd code, everything works fine. Which all points to a problem in your host controller code :) Again, do you have a pointer to your driver code where we can see it? thanks, greg k-h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ 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] question about new usb-skeleton.c code
Am Donnerstag, 15. Dezember 2005 16:58 schrieb Sam Bishop: It's the writes I'm wondering about. It appears that the code allocates a new URB and buffer for each write. Once the write is completed, the associated URB and buffer are freed. But one of the ways I benchmark our download speeds is by filling a 4K buffer with valid packets and looping over a single write(2) call. With the CPU being so much faster than USB and an URB/buffer pair being allocated for each write, it would seem like it wouldn't be long before an -ENOMEM was returned. Of course, one answer would be, Don't do that! But with a sizable number of testers connected to the same host, I could see the result being the same, or similar, even during normal usage. What am I missing? You are missing that you are looking at an example. If the problem appears in real life, you need to have some reasonable upper limit, eg. by using a semaphore. Although this is a denial of service issue and possibly the skeleton driver should deal with this issue. Regards Oliver --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=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] More USB stack hangs after sporadic disconnect
We too are having long term problems with a spontaneous USB disconnect hanging khubd. The only way to fix is a reboot. The hardware is VIA EPIA 1GHz Nehemiah running a stock 2.6.14.3 kernel with latest 117 test VIA bios. It's not a specific USB driver problem as is occurs with various USB devices (pen drive, FX2, etc). All are ehci devices. It's not power, connector, cable or grounding related. The disconnects only happen running Linux, running Win2K or WinXP never sees a spontaneous disconnect. The problem also takes from 4 to 36 hours to occur. This is the important part of trying to reproduce the disconnect, you must leave the ehci device connected for a long time, sometimes for up to two days. System load does not matter. The issue is that same with all versions of kernels that we have tried up to the current 2.6.14.3. I'm looking for help in discovering why the disconnect happens and possible solutions. We can do the grunt work here, I'm just looking for pointers from the Linux USB experts on where look and what to start looking for. From what I gather in praying to google over the last six months, many VIA chipset Linux users are seeing hints of this problem. We have some systems that never disconnect (rare), some that disconnect quickly (also rare), some that take much longer (the rest). All the systems are have identical hardware, identical software. Thanks Scott --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ 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] question about new usb-skeleton.c code
Am Donnerstag, 15. Dezember 2005 16:58 schrieb Sam Bishop: It's the writes I'm wondering about. It appears that the code allocates a new URB and buffer for each write. Once the write is completed, the associated URB and buffer are freed. But one of the ways I benchmark our download speeds is by filling a 4K buffer with valid packets and looping over a single write(2) call. With the CPU being so much faster than USB and an URB/buffer pair being allocated for each write, it would seem like it wouldn't be long before an -ENOMEM was returned. Of course, one answer would be, Don't do that! But with a sizable number of testers connected to the same host, I could see the result being the same, or similar, even during normal usage. On second thought, the skeleton driver doesn't even limit the buffersize to something sane. Triggering 128K allocations in unlimited numbers is not nice at all. Regards Oliver --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ 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] for file_storage startexit function switch
On Thu, 15 Dec 2005, tong changda wrote: hello I confused about the best way to start and stop g_file_storage function, We know that before start g_file_storage, we must unmount filesystem then after exit it , need to mount it.Why this function not be a part of function existing in file_storage.c? There are four reasons: 1. I never thought of it. 2. I don't know how to test from within a device driver whether a device or file contains a mounted filesystem, or how to tell what the mount options are. 3. I don't know how to unmount a filesystem from within a device driver. 4. I don't know how to remount a filesystem from within a device driver. Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ 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] device not accepting address
On Thu, 15 Dec 2005, driversbin driversbin wrote: hi, I am using 2.6.11 kernel patched with 2.6.12 patches for usb. USB device is host-host cable from prolific (product=0x2501, vendor=0x063) The demsg output along with the prints on minicom: usb 1-2: device descriptor read/64, error -110 usb 1-2: new full speed USB device using s3c2410-ohci and address 35 usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -110 ... After this type of behaviour, the usb device will not be configured for any successive plug-out and plug-in or changing the ends. The device has to be rebooted so that the cable gets recognised the next time. Do you mean that the _computer_ has to be rebooted? can anyone please reply what may be going wrong is it from the hub driver or from the device specific driver ? what changes have to be done or where does the problem exactly lie? Most likely the problem lies in your host-to-host cable. But if rebooting the computer always fixes the problem, then it's in the computer. It could be a problem with the USB hardware or one of the drivers. There's no way to tell at present. Your best approach is to upgrade to 2.6.14. If that doesn't help, try using the cable on a different computer. Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ 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] [QUESTION] HCD's suspend implementation
On Thu, 15 Dec 2005, Franck wrote: Hi, I'm looking at the USB suspend code of kernel 2.6.15-rc5. It seems that it has changed a lot since 2.6.14, and I'm quite confused on how to implement the suspend feature for a HCD. Actually the hcd can be suspended itself (driver suspend) or it can be asked to suspend the bus through its root hub. For the first case (driver suspend), does the HCD need to suspend the bus ? No, the bus should already be suspended. In fact, you should fail the driver-suspend request if the bus isn't already suspended. Likewise, you should fail a bus-resume request if the driver is suspended. Another question regarding root hub. Does it need to support SET_FEATURE PORT_SUSPEND request ? I don't think so because usb core seems to call hcd-bus_suspend to achieve that... No, you're confused. The root hub _does_ need to support that request, because that's how you suspend a device plugged into the root hub. To suspend the root hub itself, you would need to send this request to the root hub's parent -- which doesn't exist. On the other hand, the root hub _is_ allowed to ignore the DEVICE_REMOTE_WAKEUP feature. It never gets sent to the root hub; instead remote wakeup is assumed to be enabled and can be disabled through sysfs. Alan Stern --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] Gadgetfs issues
Dave:
I ran into some difficulties with gadgetfs and your sample usermode driver
program recently. Easy part first -- here is a patch you might want to
add to the driver program. Simple changes.
Index: gadget/usb.c
===
--- gadget.orig/usb.c
+++ gadget/usb.c
@@ -1,5 +1,5 @@
/* cc -Wall -g -Ikernel2x/include -o usb usb.c usbstring.c -lpthread */
-/* optionally with -DAIO with a recent 2.6 gadgetfs */
+/* optionally with -DAIO -laio with a recent 2.6 gadgetfs */
/*
* this is an example pthreaded USER MODE driver implementing a
@@ -243,8 +243,9 @@ static int autoconfig ()
{
struct stat statb;
- /* NetChip 2280 PCI device, high/full speed */
- if (stat (DEVNAME = net2280, statb) == 0) {
+ /* NetChip 2280 PCI device or dummy_hcd, high/full speed */
+ if (stat (DEVNAME = net2280, statb) == 0 ||
+ stat (DEVNAME = dummy_udc, statb) == 0) {
HIGHSPEED = 1;
device_desc.bcdDevice = __constant_cpu_to_le16 (0x0100),
@@ -378,8 +379,9 @@ static int iso_autoconfig ()
*/
device_desc.idProduct = __constant_cpu_to_le16(DRIVER_ISO_PRODUCT_NUM);
- /* NetChip 2280 PCI device, high/full speed */
- if (stat (DEVNAME = net2280, statb) == 0) {
+ /* NetChip 2280 PCI device or dummy_hcd, high/full speed */
+ if (stat (DEVNAME = net2280, statb) == 0 ||
+ stat (DEVNAME = dummy_udc, statb) == 0) {
unsignedbInterval, wMaxPacketSize;
HIGHSPEED = 1;
@@ -549,7 +551,7 @@ static void close_fd (void *fd_ptr)
* whether or not the host is connected
*/
static int
-ep_config (char *name, char *label,
+ep_config (char *name, const char *label,
struct usb_endpoint_descriptor *fs,
struct usb_endpoint_descriptor *hs
)
The main issue with gadgetfs is that it never terminates short control
responses with a zero-length packet. This shows up clearly with the user
driver since the serial-number string is 31 characters, which becomes 62
bytes in Unicode plus the 2-byte descriptor header. The host asks for a
255-byte transfer, it receives the 64-byte response in a single packet,
and then the request times out. Below is a patch to fix the problem; I
don't know if this is the best way but it seems to work.
That is, it seems to work when using dummy_hcd. It doesn't work with
net2280, and I can only conclude that the net2280 code does not support
req-zero on ep0! (I haven't tried other endpoints.) Too bad there's no
way to check this out using usbtest. Do you have any idea what could be
going on?
Alan Stern
Change gadgetfs to add a zero-length packet when needed for a short
response on ep0. Also allow support for high-speed operation by default.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/gadget/inode.c
===
--- usb-2.6.orig/drivers/usb/gadget/inode.c
+++ usb-2.6/drivers/usb/gadget/inode.c
@@ -22,6 +22,7 @@
// #define DEBUG /* data to help fault diagnosis */
// #define VERBOSE /* extra debug messages (success too) */
+#defineHIGHSPEED
#include linux/init.h
#include linux/module.h
@@ -135,6 +136,7 @@ struct dev_data {
setup_out_ready : 1,
setup_out_error : 1,
setup_abort : 1;
+ unsignedsetup_wLength;
/* the rest is basically write-once */
struct usb_config_descriptor*config, *hs_config;
@@ -942,6 +944,7 @@ static int setup_req (struct usb_ep *ep,
}
req-complete = ep0_complete;
req-length = len;
+ req-zero = 0;
return 0;
}
@@ -1161,10 +1164,13 @@ ep0_write (struct file *fd, const char _
spin_unlock_irq (dev-lock);
if (copy_from_user (dev-req-buf, buf, len))
retval = -EFAULT;
- else
+ else {
+ if (len dev-setup_wLength)
+ dev-req-zero = 1;
retval = usb_ep_queue (
dev-gadget-ep0, dev-req,
GFP_KERNEL);
+ }
if (retval 0) {
spin_lock_irq (dev-lock);
clean_req (dev-gadget-ep0, dev-req);
@@ -1483,6 +1489,7 @@ unrecognized:
delegate:
dev-setup_in = (ctrl-bRequestType USB_DIR_IN)
? 1 : 0;
+
Re: [linux-usb-devel] question about new usb-skeleton.c code
Oliver Neukum wrote: On second thought, the skeleton driver doesn't even limit the buffersize to something sane. Triggering 128K allocations in unlimited numbers is not nice at all. Regards Oliver That's right; I forgot that I'd seen that too. I suppose this is the difference between a skeleton and an example? :) As you mentioned, any limit on the number of URBs in flight would require a counting semaphore or some other kind of locking. There's a comment at the top of the code extolling the fact that there is no locking, which made me think that issues like this were now being handled lower in the kernel--which I admit doesn't make much sense. As things stand though, I could see this turning into a FAQ. Thank you for your time! Sam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ 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] question about new usb-skeleton.c code
On Thu, Dec 15, 2005 at 08:58:39AM -0700, Sam Bishop wrote: Hello, I maintain a 2.4 USB driver based off an old version of usb-skeleton.c. (It's for an in-house tester used where I work, and the choice of kernel version is out of my hands.) I've just taken a look at the latest (2.6) version of usb-skeleton.c, and I'm wondering if someone would be generous enough to explain to me how a part of it works. It's the writes I'm wondering about. It appears that the code allocates a new URB and buffer for each write. Once the write is completed, the associated URB and buffer are freed. But one of the ways I benchmark our download speeds is by filling a 4K buffer with valid packets and looping over a single write(2) call. With the CPU being so much faster than USB and an URB/buffer pair being allocated for each write, it would seem like it wouldn't be long before an -ENOMEM was returned. You are right, as Oliver pointed out. If you look at drivers that copy this scheme (like visor.c), they put an upper limit on the number of urbs that can be in flight at any one time. I'd be glad to accept a change to the usb-skeleton.c driver that adds this logic if you want to make up a patch. thanks, greg k-h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=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] HID driver for extra keys on keyboard
Hi, I have a MS keyboard which is USB-only and has 3 interfaces: 1. Normal keyboard 2. Extra keys (there are many - volume controls, favourite buttons, application buttons, ...) 3. Fingerprint reader I'm trying to get the 2nd interface going with Linux. It's HID descriptor is: : 05 0c 09 01 a1 01 85 01 05 0c 19 00 2a ff ff 95 0010: 01 75 10 15 00 27 ff ff 00 00 81 00 05 07 19 00 0020: 29 ff 75 08 26 ff 00 81 00 81 01 06 00 ff 0a 03 0030: fe 0a 04 fe 95 02 75 01 25 01 81 02 0a 05 ff 95 0040: 01 75 05 25 1f 81 02 75 09 81 01 0a 02 ff 26 ff 0050: 00 75 08 81 02 c0 05 01 09 80 a1 01 85 03 19 00 0060: 29 ff 15 00 26 ff 00 81 00 c0 The lsusb -v output is attached. The current usbhid driver (2.6.15-rc5) tries to claim the device, but fails: drivers/usb/input/hid-core.c: HID probe called for ifnum 1 drivers/usb/input/hid-core.c: usage index exceeded drivers/usb/input/hid-core.c: hid_add_usage failed drivers/usb/input/hid-core.c: item 0 2 2 2 parsing failed drivers/usb/input/hid-core.c: parsing report descriptor failed I think this is because early on in the descriptor, it defines a range of 0-65535 (bigger than HID_MAX_USAGES): Item(Global): Usage Page, data= [ 0x0c ] 12 Consumer Item(Local ): Usage Minimum, data= [ 0x00 ] 0 Unassigned Item(Local ): Usage Maximum, data= [ 0xff 0xff ] 65535 (null) In hid_parser_local() where it processes HID_LOCAL_ITEM_TAG_USAGE_MAXIMUM the value of data is actually 851967. I haven't looked into this, but adding in a hack to set it as 0x29C (the last usage ID in consumer tables) gives some success: Dec 15 23:51:53 dsd drivers/usb/input/hid-core.c: HID probe called for ifnum 1 Dec 15 23:51:53 dsd drivers/usb/input/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0101 wIndex=0x0001 wLength=8Dec 15 23:51:53 dsd hid-debug: input ff00.fe03 = 1 Dec 15 23:51:53 dsd hid-debug: input ff00.fe04 = 0 Dec 15 23:51:53 dsd hid-debug: input ff00.ff05 = 0 Dec 15 23:51:53 dsd hid-debug: input ff00.ff02 = 0 Dec 15 23:51:53 dsd drivers/usb/input/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0103 wIndex=0x0001 wLength=2 Dec 15 23:51:53 dsd INPUT(1)[INPUT] Dec 15 23:51:53 dsd Field(0) Dec 15 23:51:53 dsd Usage(256) Dec 15 23:51:53 dsd Keyboard. Dec 15 23:51:53 dsd Keyboard.0001 snip Dec 15 23:51:53 dsd Keyboard.00fe Dec 15 23:51:53 dsd Keyboard.00ff Dec 15 23:51:53 dsd Logical Minimum(0) Dec 15 23:51:53 dsd Logical Maximum(255) Dec 15 23:51:53 dsd Report Size(8) Dec 15 23:51:53 dsd Report Count(1) Dec 15 23:51:53 dsd Report Offset(16) Dec 15 23:51:53 dsd Flags( Array Absolute ) Dec 15 23:51:53 dsd Field(1) Dec 15 23:51:53 dsd Usage(2) Dec 15 23:51:53 dsd ff00.fe03 Dec 15 23:51:53 dsd ff00.fe04 Dec 15 23:51:53 dsd Logical Minimum(0) Dec 15 23:51:53 dsd Logical Maximum(1) Dec 15 23:51:53 dsd Report Size(1) Dec 15 23:51:53 dsd Report Count(2) Dec 15 23:51:53 dsd Report Offset(32) Dec 15 23:51:53 dsd Flags( Variable Absolute ) Dec 15 23:51:53 dsd Field(2) Dec 15 23:51:53 dsd Usage(1) Dec 15 23:51:53 dsd ff00.ff05 Dec 15 23:51:53 dsd Logical Minimum(0) Dec 15 23:51:53 dsd Logical Maximum(31) Dec 15 23:51:53 dsd Report Size(5) Dec 15 23:51:53 dsd Report Count(1) Dec 15 23:51:53 dsd Report Offset(34) Dec 15 23:51:53 dsd Flags( Variable Absolute ) Dec 15 23:51:53 dsd Field(3) Dec 15 23:51:53 dsd Usage(1) Dec 15 23:51:53 dsd ff00.ff02 Dec 15 23:51:53 dsd Logical Minimum(0) Dec 15 23:51:53 dsd Logical Maximum(255) Dec 15 23:51:53 dsd Report Size(8) Dec 15 23:51:53 dsd Report Count(1) Dec 15 23:51:53 dsd Report Offset(48) Dec 15 23:51:53 dsd Flags( Variable Absolute ) Dec 15 23:51:53 dsd INPUT(3)[INPUT] Dec 15 23:51:53 dsd Field(0) Dec 15 23:51:53 dsd Usage(256) Dec 15 23:51:53 dsd GenericDesktop. Dec 15 23:51:53 dsd GenericDesktop.Pointer Dec 15 23:51:53 dsd GenericDesktop.Mouse Dec 15 23:51:53 dsd GenericDesktop.0003 Dec 15 23:51:53 dsd GenericDesktop.Joystick Dec 15 23:51:53 dsd GenericDesktop.GamePad Dec 15 23:51:53 dsd GenericDesktop.Keyboard Dec 15 23:51:53 dsd GenericDesktop.Keypad Dec 15 23:51:53 dsd GenericDesktop.MultiAxis Dec 15 23:51:53 dsd GenericDesktop.0009 Dec 15 23:51:53 dsd GenericDesktop.000a snip Dec 15 23:51:53 dsd GenericDesktop.002f Dec 15 23:51:53 dsd GenericDesktop.X Dec 15 23:51:53 dsd GenericDesktop.Y Dec 15 23:51:53 dsd GenericDesktop.Z Dec 15 23:51:53 dsd GenericDesktop.Rx Dec 15 23:51:53 dsd GenericDesktop.Ry Dec 15 23:51:53 dsd GenericDesktop.Rz Dec 15 23:51:53 dsd GenericDesktop.Slider Dec 15 23:51:53 dsd GenericDesktop.Dial Dec 15 23:51:53 dsd GenericDesktop.Wheel Dec 15 23:51:53 dsd GenericDesktop.HatSwitch Dec 15 23:51:53 dsd GenericDesktop.CountedBuffer Dec 15 23:51:53 dsd GenericDesktop.ByteCount Dec 15 23:51:53 dsd GenericDesktop.MotionWakeup Dec 15 23:51:53 dsd GenericDesktop.Start Dec 15 23:51:53 dsd
[linux-usb-devel] Re: HID driver for extra keys on keyboard
Daniel Drake wrote:
The lsusb -v output is attached.
Missed it. Here it is.
Bus 002 Device 002: ID 045e:00bb Microsoft Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x045e Microsoft Corp.
idProduct 0x00bb
bcdDevice1.00
iManufacturer 1 Microsoft
iProduct2 Microsoft® Keyboard with Fingerprint Reader
iSerial 3 {A4FAB6BC-B27C-E44D-9156-CDBBEA9359D3}
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 82
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
Remote Wakeup
MaxPower 260mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Devices
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType33
bcdHID 1.11
bCountryCode0 Not supported
bNumDescriptors 1
bDescriptorType34 Report
wDescriptorLength 60
Report Descriptor: (length is 60)
Item(Global): Usage Page, data= [ 0x01 ] 1
Generic Desktop Controls
Item(Local ): Usage, data= [ 0x06 ] 6
Keyboard
Item(Main ): Collection, data= [ 0x01 ] 1
Application
Item(Global): Usage Page, data= [ 0x08 ] 8
LEDs
Item(Local ): Usage Minimum, data= [ 0x01 ] 1
NumLock
Item(Local ): Usage Maximum, data= [ 0x03 ] 3
Scroll Lock
Item(Global): Logical Minimum, data= [ 0x00 ] 0
Item(Global): Logical Maximum, data= [ 0x01 ] 1
Item(Global): Report Size, data= [ 0x01 ] 1
Item(Global): Report Count, data= [ 0x03 ] 3
Item(Main ): Output, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Local ): Usage, data= [ 0x4b ] 75
Generic Indicator
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Main ): Output, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Global): Report Count, data= [ 0x04 ] 4
Item(Main ): Output, data= [ 0x01 ] 1
Constant Array Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Global): Usage Page, data= [ 0x07 ] 7
Keyboard
Item(Local ): Usage Minimum, data= [ 0xe0 ] 224
Control Left
Item(Local ): Usage Maximum, data= [ 0xe7 ] 231
GUI Right
Item(Global): Report Count, data= [ 0x08 ] 8
Item(Main ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x01 ] 1
Item(Main ): Input, data= [ 0x01 ] 1
Constant Array Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Local ): Usage Minimum, data= [ 0x00 ] 0
No Event
Item(Local ): Usage Maximum, data= [ 0x91 ] 145
LANG 2 (Hanja Conversion, Korea)
Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
Item(Global): Report Count, data= [ 0x06 ] 6
Item(Main ): Input, data= [ 0x00 ] 0
Data Array Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
Item(Main ): End Collection, data=none
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes3
Transfer TypeInterrupt
Synch
RE: [linux-usb-devel] Freescale MPC83XX USB Host Support
The USB host support for MPC8349 is already done and included in freescale released BSP. But the patch is not submitted to the community yet. However, MPC836x use totally different USB controller and doesn't have a working Linux driver now. I don't know which one you refer to by using MPC83xx. Best Regards, Leo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KRONSTORFER Horst Sent: Wednesday, December 14, 2005 10:03 PM To: linux-usb-devel@lists.sourceforge.net Subject: [linux-usb-devel] Freescale MPC83XX USB Host Support hi! i'm about to start working on this. anybody else? -h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ 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] More USB stack hangs after sporadic disconnect
On Thu, Dec 15, 2005 at 01:16:24PM -0500, Scott D. Davilla wrote: We too are having long term problems with a spontaneous USB disconnect hanging khubd. The only way to fix is a reboot. The hardware is VIA EPIA 1GHz Nehemiah running a stock 2.6.14.3 kernel with latest 117 test VIA bios. It's not a specific USB driver problem as is occurs with various USB devices (pen drive, FX2, etc). All are ehci devices. It's not power, connector, cable or grounding related. The disconnects only happen running Linux, running Win2K or WinXP never sees a spontaneous disconnect. The problem also takes from 4 to 36 hours to occur. This is the important part of trying to reproduce the disconnect, you must leave the ehci device connected for a long time, sometimes for up to two days. System load does not matter. The issue is that same with all versions of kernels that we have tried up to the current 2.6.14.3. I'm looking for help in discovering why the disconnect happens and possible solutions. We can do the grunt work here, I'm just looking for pointers from the Linux USB experts on where look and what to start looking for. From what I gather in praying to google over the last six months, many VIA chipset Linux users are seeing hints of this problem. We have some systems that never disconnect (rare), some that disconnect quickly (also rare), some that take much longer (the rest). All the systems are have identical hardware, identical software. Via usb controllers are known to have problems :( If you insert a ehci pci card in the machine, does the same problem happen? And, what are the kernel log messages that happen when the disconnect happens (if you enable CONFIG_USB_DEBUG, it would help.) thanks, greg k-h --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
