gmane.linux.usb.general

Fwd: Re: Bluetooth and "IRQ 19 and nobody cared" on a HP 8510w with Debian 2.6.24 or 2.6.26

Tyson Whitehead — 2008-12-01T15:38:27

As suggested, I'm forwarding this to you "usb guys". : ) I still have to try the btusb driver as Marcel suggested (it does not appear to be built in the standard Debian kernel, so this might take awhile). If the the problem persists with it, I'll send a follow up email. Thanks! -Tyson PS: By the way Marcel, thanks for the follow up. ---------- Forwarded Message ---------- From: Marcel Holtmann To: Tyson Whitehead Hi Tyson, start using the btusb driver instead of hci_usb. And even while you think this might be caused by Bluetooth, you should report it to the USB guys since the USB host controller is responsible for that interrupt. Regards Marcel ------------------------------------------------------- Bus 004 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x0

[PATCH] USB: skip Set-Interface(0) if already in altsetting 0

Alan Stern — 2008-12-01T15:24:41

When a driver unbinds from an interface, usbcore always sends a Set-Interface request to reinstall altsetting 0. Unforunately, quite a few devices have buggy firmware that crashes when it receives this request. To avoid such problems, this patch (as1180) arranges to send the Set-Interface request only when the interface is not already in altsetting 0. Signed-off-by: Alan Stern public.gmane.org> --- Index: usb-2.6/drivers/usb/core/driver.c =================================================================== --- usb-2.6.orig/drivers/usb/core/driver.c +++ usb-2.6/drivers/usb/core/driver.c < at >< at > -295,7 +295,9 < at >< at > static int usb_unbind_interface(struct d * altsetting means creating new endpoint device entries). * When either of these happens, defer the Set-Interface. */ -if (!error && intf->dev.power.status == DPM_ON) +if (intf->cur_altsetting->desc.bAlternateSetting == 0) +;/* Already in altsetting 0 so skip Set-Interface */ +else if (!error && intf->dev.pow

[PATCH] USB: fix comment about endianness of descriptors

Alan Stern — 2008-12-01T15:22:33

From: Phil Endecott public.gmane.org> This patch fixes a comment and clarifies the documentation about the endianness of descriptors. The current policy is that descriptors will be little-endian at the API even on big-endian systems; however the /proc/bus/usb API predates this policy and presents descriptors with some multibyte fields byte-swapped. Signed-off-by: Phil Endecott public.gmane.org> Signed-off-by: Alan Stern public.gmane.org> --- Index: usb-2.6/Documentation/usb/proc_usb_info.txt =================================================================== --- usb-2.6.orig/Documentation/usb/proc_usb_info.txt +++ usb-2.6/Documentation/usb/proc_usb_info.txt < at >< at > -49,8 +49,10 < at >< at > it and 002/048 sometime later. These files can be read as binary data. The binary data consists of first the device descriptor, then the descriptors for each -configuration of the device. That informati

(unknown)

Sebastian Andrzej Siewior — 2008-12-01T10:47:39

Hi Greg, this could be a repost. According to David the emails were dropped due to a header error. this two pathes contain fixes in PCI setup code. The first one is a 'make-it-work-it-did-not-work-before' and second makes sure the driver does not feel responsible for all bridges. The latter is due to an Email I received from a person. He complained that this driver probed and "tried" to work with his device in 2.6.27.7. Therefore it would be nice if you could push both stable. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[GIT PATCH] USB fixes for 2.6.28-git

Greg KH — 2008-12-01T06:16:00

Here are a few USB fixes against your current git tree. These patches are: - revert ehci patch that was incorrect - fix for a different broken AMD USB controller - 2 gadget bugfixes - usb storage quirks - new device ids Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ All of these patches have been in the -next and -mm tree for a few releases. The full patches will be sent to the linux-usb mailing list, if anyone wants to see them. thanks, greg k-h ------------------ drivers/usb/gadget/fsl_qe_udc.c | 3 +++ drivers/usb/gadget/fsl_usb2_udc.c | 3 +++ drivers/usb/host/ehci-pci.c | 9 ++++++--- drivers/usb/host/ehci.h | 12 +++++------- drivers/usb/serial/option.c | 35 +++++++++++++++++++++++++++++++++++ drivers/usb/storage/unusual_devs.h | 19 +++++++++++++++++++ 6 files changed, 71 insertions(+), 10 deletions(-) --------------- Alan Stern (1): USB: storage: unusual_devs entry for Mio C520-GPS Anton Vorontsov

OHCI bad entry problem

Endre Bakka — 2008-12-01T03:41:56

Hi, I have a custom board with an Altera FPGA running uClinux (2.6.27 kernel) on a Nios2 soft core processor, a ISP1564 USB controller and a Zydas based Wi-Fi USB stick. I'm trying to get the wi-fi stick working using the zd1211rw driver and the ohci driver. It works fine for a short while - I am usually able to do a iwlist scanning and sometimes it even manages to run a dhcp client to obtain an IP address, but then I get a bad entry error. After this e.g. iwlist scanning only returns "wlan0 Interface doesn't support scanning" or "wlan0 Failed to read scan data : Resource temporarily unavailable". I have also tried the vendor based driver and gotten the same results (although the first time I tried it, I seemed to get a lot further before the bad entry problem showed up). I added some debug statements to the ohci driver, and to me it seems to get an errounous TD from the host controller. I am hoping somebody can provide me with additional pointers on what goes wrong (and even bett

WG: Blocking read [gadgetfs with Kernel 2.6.27]

Manuel Sahm — 2008-11-30T17:25:30

Hello, I need help - very urgent. I use Kernel 2.6.27 with gadgetfs for my usb device. I have an AT91SAM9260 Microcontroller. I'm using the example usb.c from linux-usb.org to configure the usb device. I use 2 bulk endpoints to transfer/receive data from/to a host. I want to poll the endpoint using the read() function, the problem is, that the function never returns if no data is available. I have tried select() and poll() but both functions always return 1. How could I achieve that read() returns with a defined status, for example 0, if no data is available. Thank you very much for your help. Best regards Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH v2] Fix comment about endianness of descriptors

Phil Endecott — 2008-11-30T13:49:07

This patch fixes a comment and clarifies the documentation about the endianness of descriptors. The current policy is that descriptors will be little-endian at the API even on big-endian systems; however the /proc/bus/usb API predates this policy and presents descriptors with some multibyte fields byte-swapped. Signed-off-by: Phil Endecott public.gmane.org> ---- diff --git a/Documentation/usb/proc_usb_info.txt b/Documentation/usb/proc_usb_info.txt index 077e903..600ac1a 100644 --- a/Documentation/usb/proc_usb_info.txt +++ b/Documentation/usb/proc_usb_info.txt < at >< at > -49,8 +49,10 < at >< at > it and 002/048 sometime later. These files can be read as binary data. The binary data consists of first the device descriptor, then the descriptors for each -configuration of the device. That information is also shown in -text form by the /proc/bus/usb/devices file, described later. +configuration of the device. Multi-byte fields in the device and +configuration descriptors, but no

USB gadget: best way to force reenumeration?

Mike Lockwood — 2008-11-29T22:34:17

I am working on a composite gadget driver that needs to change its PID and the number of interfaces in its configuration dynamically. In our current (non-gadget) implementation, we are doing this by forcing a reset so the host will reenumerate and recognize the new interface. What is the best way to do this using the gadget API, so the driver will be portable to other USB controllers? usb_gadget_connect/usb_gadget_disconnect and usb_gadget_vbus_connect/usb_gadget_vbus_disconnect look promising, but I don't know if that would work with all gadget controller drivers. If there were a usb_remove_function() call to match usb_add_function(), that might solve my problem too, but the fact that usb_add_function() is in __init implies it is not intended to be called after the driver is initialized. Or would it be better to add a usb_gadget_reset() function to the API for this purpose? thanks, Mike

PCI ID + Subsystem IDs of the isp1761-pci eval card.

Sebastian Andrzej Siewior — 2008-11-29T18:58:24

Hi Karl, since you sent a patch to fixup the PCI glue code for the ISP176x I assume you have the eval kit from NXP, don't you? Would be so kind and post the output of lspci -vn -s slot where slot is the slot of the NXP chip resp. his PLX? The thing is that I don't have the card anymore and the driver registers itself as the miracle driver that can handle any PLX bridge. So what I would like to do, is to make the driver register a specific bridge + vendor id + device id + subvendor id + subdevice id. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] Fix comment about endianness of descriptors

Phil Endecott — 2008-11-28T22:58:47

This patch fixes a comment and clarifies the documentation about the endianness of descriptors. The current policy is that descriptors will be little-endian at the API even on big-endian systems; however the /proc/bus/usb API predates this policy and presents descriptors with multibyte fields byte-swapped when necessary. Signed-off-by: Phil Endecott public.gmane.org> ---- diff --git a/Documentation/usb/proc_usb_info.txt b/Documentation/usb/proc_usb_info.txt index 077e903..94c8789 100644 --- a/Documentation/usb/proc_usb_info.txt +++ b/Documentation/usb/proc_usb_info.txt < at >< at > -49,8 +49,10 < at >< at > it and 002/048 sometime later. These files can be read as binary data. The binary data consists of first the device descriptor, then the descriptors for each -configuration of the device. That information is also shown in -text form by the /proc/bus/usb/devices file, described later. +configuration of the device. Multi-byte fields in the descriptors +are converted to host

option: oops on unload (2.6.27.4)

Marcin Slusarz — 2008-11-28T21:32:59

It's not new bug - I've seen this oops many times but on much older kernels (2.6.18, probably on 2.6.24 too). I tried to rmmod it (and all usb modules) because sometimes it helps when modem disconnects and can't connect again. [25350.138850] BUG: unable to handle kernel paging request at e0857fb4 [25350.138866] IP: [] :usbcore:unlink1+0xab/0xb9 [25350.138921] *pde = 1f80f067 *pte = 00000000 [25350.138934] Oops: 0000 [#1] PREEMPT SMP [25350.138945] Modules linked in: r128 drm ipt_REDIRECT ipt_MASQUERADE xt_tcpudp xt_multiport iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_filter ip_tables ppp_deflate zlib_deflate zlib_inflate bsd_comp ppp_async crc_ccitt ppp_generic slhc ipt_REJECT x_tables loop option usbserial snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd 8139cp i2c_i801 floppy 8139too 3c59x psmouse intel_agp soundcore snd_page_alloc sg mii usbcore agpgart i2c_core sr_mod evdev dcdbas cdrom [last unloaded: uhci_hcd] [25350.139052] [25350.139059] Pid: 2807, comm: pppd N

Endianness of /sys descriptors attribute vs. usbfs descriptors

Phil Endecott — 2008-11-28T14:52:13

Dear Experts, I've just been comparing the code in core/sysfs.c read_descriptors() (which provides /sys/bus/usb/devices/*/descriptors) and core/devio.c usbdev_read() (which provides the descriptors you get when you read from a usbfs node). It looks as if the latter calls le16_to_cpu for all the 16-bit fields in the device descriptor while the former doesn't. The same applies to the wTotalLength field in the config descriptor; however, neither byteswaps the wMaxPacketSize field in the endpoint descriptor (which is the only other 16-bit field I can think of). Of course most of us will never notice any bugs of this sort on our little-endian machines.... Have I missed something, or is there a problem here? Cheers, Phil. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] gadget: Add support for OTG controller on i.MX31 SoCs in device mode

Guennadi Liakhovetski — 2008-11-28T11:58:43

This driver is based on the sources from Freescale. All parts that I cannot test have been removed, so, only a pure device mode and only one ULPI transceiver supported. Has been tested with ethernet and file-storage gadgets. Signed-off-by: Guennadi Liakhovetski public.gmane.org> --- I tried to clean this up as much as I could, but I cannot state, that I have reviewed every single line. Otherwise, seems to work well, stable, delivers good transfer rates with ethernet and file-storage in HS mode. diff --git a/arch/arm/plat-mxc/include/mach/arc_otg.h b/arch/arm/plat-mxc/include/mach/arc_otg.h new file mode 100644 index 0000000..8401d9a --- /dev/null +++ b/arch/arm/plat-mxc/include/mach/arc_otg.h < at >< at > -0,0 +1,155 < at >< at > +/* + * Copyright 2005-2007 Freescale Semiconductor, Inc. All Rights Reserved. + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * +

We have a slight problem with the hso driver & I'm looking for advise

Denis Joseph Barrow — 2008-11-28T09:19:31

Hi Guys, There used be a check in the old 1.3 hso driver for a urb status of -EINPROGRESS before all calls to usb_kill_urb & usb_unlink_urb this check has been taken out of the hso driver. Now we are having a fairly serious kernel oops in usb_kill_urb when the device is disconnected in linux-2.6.23.9lw as on the acer aspire one which affects system stability. Should I put this check back in to the official linux kernel driver & the one from option which supports multiple kernel versions. Any advise you might have would be greatly appreciated.

Device continuously dis- and reconnects

Florian Echtler — 2008-11-26T12:40:33

Hello everyone, I recently got a weird little NFC-based card reader which poses as a HID keyboard. The device is based on the AT91SAM7S64 microcontroller. While it works under Windows, I failed to get it to run on any of the three Linux machines I tried. All of them have an UHCI host controller; I'll try OHCI when I find a machine which has one. The problem is that while the device is recognized, it disconnects and reconnects in five-second intervals (and isn't usable in between). I compiled my uhci-hcd driver with additional debugging information and have attached an excerpt from the messagelog, so maybe somebody can give me a hint.. Thanks, Yours, Florian

LPM (L1 sleep) hub class feature selector

Raghavendra reddy — 2008-11-26T10:54:47

Hi, The Hub class Feature selector for L1 sleep deviates from what is defined in the spec " USB 2.0 LPM ECN " ( as PORT_L1 10 ) . -------------------- hub.h /* * Port feature numbers * See USB 2.0 spec Table 11-17 */ #define USB_PORT_FEAT_CONNECTION 0 #define USB_PORT_FEAT_ENABLE 1 #define USB_PORT_FEAT_SUSPEND 2 /* L2 suspend */ #define USB_PORT_FEAT_OVER_CURRENT 3 #define USB_PORT_FEAT_RESET 4 #define USB_PORT_FEAT_L1 5 /* L1 suspend */ #define USB_PORT_FEAT_POWER 8 #define USB_PORT_FEAT_LOWSPEED 9 #define USB_PORT_FEAT_HIGHSPEED 10 # ----------------------- Is there any reason for not using 10 (which of course is used by USB_PORT_FEAT_HIGHSPEED ) and going for 5. Also, is there any patch available for LPM implementation for EHCI. Thanks, Raghav -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

WG: usb_bulk_msg questions

WILLMS, Martin — 2008-11-26T08:33:31

Hello, I am developing a Linux USB driver for one of our devices (data logger). It uses a Cypress EZ USB (High Speed) controller attached to an FPGA via the direct FIFO access. I am using Bulk In transfers to get data from the endpoint at very high speed. I am collecting data from the device using the usb_bulk_msg function. For this purpose I call the function using an external data buffer for the received bytes. The buffer, the data is stored in by the usb_bulk_msg function is allocated using kmalloc as GFP_KERNEL. Problem: If using a host with USB 1.1 controller (Full Speed), the data transfers are working fine. All data is received from the device. If using a host with USB 2.0 (High Speed) controller sometimes data is missing. If data is missing, allways whole USB packets (512 bytes) are missing. I see this in the recorded data. The number of bytes that is returned by the usb_bulk_msg function is allready missing the bytes, too. i_urb_submit = usb_bulk_msg (dev, usb_rcvbulkpipe

FW: [PATCH 2.6.27] usb isp1760: initialize port 1 of ISP1761

Hommel, Thomas (GE EntSol, Intelligent Platforms — 2008-11-26T07:27:25

This patch enables port 1 as a host controller port on an ISP1761 chip. On this chip, the register is called OTG control register, but the init value is the same as on the ISP1760. Signed-off-by: Thomas Hommel public.gmane.org> --- linux-2.6.27-vanilla/drivers/usb/host/isp1760-hcd.c +++ linux-2.6.27/drivers/usb/host/isp1760-hcd.c < at >< at > -435,10 +438,9 < at >< at > static int isp1760_hc_setup(struct usb_h /* * PORT 1 Control register of the ISP1760 is the OTG control - * register on ISP1761. + * register on ISP1761, but enabling port 1 is the same pattern */ -if (!(priv->devflags & ISP1760_FLAG_ISP1761) && -!(priv->devflags & ISP1760_FLAG_PORT1_DIS)) { +if (!(priv->devflags & ISP1760_FLAG_PORT1_DIS)) { isp1760_writel(PORT1_POWER | PORT1_INIT2, hcd->regs + HC_PORT1_CTRL); mdelay(10); Sorry again, another one. Hope this works, or this may get more and more embarrassing. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a me

[PATCH] USB: utilize round_jiffies_up_relative()

Alan Stern — 2008-11-25T21:40:02

This patch (as1178) uses the new round_jiffies_up_relative() routine for setting the autosuspend delayed_work timer. It's appropriate since we don't care too much about the exact length of the delay, but we don't want it to be too short (rounded down). Signed-off-by: Alan Stern public.gmane.org> --- Index: usb-2.6/drivers/usb/core/driver.c =================================================================== --- usb-2.6.orig/drivers/usb/core/driver.c +++ usb-2.6/drivers/usb/core/driver.c < at >< at > -1109,7 +1109,7 < at >< at > static int autosuspend_check(struct usb_ if (reschedule) { if (!timer_pending(&udev->autosuspend.timer)) { queue_delayed_work(ksuspend_usb_wq, &udev->autosuspend, -round_jiffies_relative(suspend_time - j)); +round_jiffies_up_relative(suspend_time - j)); } return -EAGAIN; } < at >< at > -1557,7 +1557,7 < at >< at > void usb_autopm_put_interface_async(stru else if (intf->pm_usage_cnt <= 0 && !timer_pending(&udev->autosuspend.timer)) { queue_delaye

[PATCH] USB: Enhance usage of pm_message_t

Alan Stern — 2008-11-25T21:39:18

This patch (as1177) modifies the USB core suspend and resume routines. The resume functions now will take a pm_message_t argument, so they will know what sort of resume is occurring. The new argument is also passed to the port suspend/resume and bus suspend/resume routines (although they don't use it for anything but debugging). In addition, special pm_message_t values are used for user-initiated, device-initiated (i.e., remote wakeup), and automatic suspend/resume. By testing these values, drivers can tell whether or not a particular suspend was an autosuspend. Unfortunately, they can't do the same for resumes -- not until the pm_message_t argument is also passed to the drivers' resume methods. That will require a bigger change. IMO, the whole Power Management framework should have been set up this way in the first place. Signed-off-by: Alan Stern public.gmane.org> --- Index: usb-2.6/include/linux/usb.h ========================================================