gmane.linux.usb.general

Re: USB reset errors in 2.6.28*

Sean MacLennan — 2008-12-04T05:02:26

On Wed, 3 Dec 2008 20:26:07 -0800 "Greg KH" public.gmane.org> wrote: I am embarrassed to say that I tried the usb with 2.6.28-rc7 and it seems to be fixed. I should have tried it with 2.6.28-rc7 *before* sending the error report :( Cheers, Sean -- 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

Re: [PATCH] Adding Ewert Energy System's CANdapter PID to FTDI_SIODriver

Greg KH — 2008-12-04T04:29:12

Somehow your patch got linewrapped and the tabs turned into spaces :( Also, can you add a "Signed-off-by:" as required by the Documentation/SubmittingPatches file and resend it? thanks, greg k-h -- 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

Re: USB reset errors in 2.6.28*

Greg KH — 2008-12-04T04:26:07

What driver is that? Why would 2.6.28 be broken? If it's an out-of-tree driver, please let me know and I'll be glad to get it merged. thanks, greg k-h -- 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

Re: [Bugme-new] [Bug 12148] New: "EHCI: BIOS handoff failed" needsto be handled better

Sarah Sharp — 2008-12-03T23:48:55

Grumble. Is there any chance you can give me the email addresses of the Intel employees who sent you this response? Off list, of course. The Intel Open Source Technology center tries to test all new Intel platforms under Linux. I'm not sure if we tested that system with the Legacy BIOS option turned on. In any case, the Intel employees should have pointed you to our group for Linux issues. Linux is a supported operating system for Intel platforms, and this sort of response is not tolerable. On Wed, Dec 03, 2008 at 04:59:28PM -0500, Alan Stern wrote: The longer answer is it's bad for the OS to set the hand-off timeout too short because the BIOS might leave the hardware (and other USB devices) in an undefined state if you take away the host controller ownership too early. That shouldn't be a problem for the OS, as the EHCI host controller driver resets the host controller as soon as it gets control. We do want to give some time for valid BIOSes to clean up their internal state before taking over th

Re: Order of /sys creation vs. uevent delivery

Kay Sievers — 2008-12-03T22:46:07

I know. That's what I meant with "extend", "add more calls". It looks like it can be moved. As long as we keep the bus_attach_device() after the ADD notifier, nothing bad should happen. In case something will depend on it, we can still just add a second pre-add notifier in the add call. The nice thing using the notifiers would be that any user can track all the state transitions of a device with the same mechanics, without the need to use device_type, or any other single-user callback. Kay -- 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

Re: bug in ehci-hcd unlink speedups

Geoff Levand — 2008-12-03T22:23:24

No, there is a hypervisor, and we can just map the HC regs. I think we can just add a check in scan_async() to see if the new timestamp is equal to the old, and if so, call start_unlink_async(). I'll make a patch and post it. Do you see anything wrong with the idea? -Geoff -- 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

Re: Order of /sys creation vs. uevent delivery

Alan Stern — 2008-12-03T22:18:18

BUS_NOTIFY_BOUND_DRIVER and BUS_NOTIFY_UNBIND_DRIVER aren't relevant to this problem. BUS_NOTIFY_ADD_DEVICE and BUS_NOTIFY_DEL_DEVICE _are_ relevant, but the timing is wrong! In particular, the ADD_DEVICE notification gets sent out before dpm_sysfs_add() is called. But USB needs to create some attributes in the power/ subdirectory, and that subdirectory is created when dpm_sysfs_add() calls sysfs_create_group(). I suppose we could move the dpm_sysfs_add() call earlier. Its timing is less important than that of device_pm_add(), for example. Does the position of the notifications matter? Could the ADD_DEVICE notification be moved to just before the uevent? Alan Stern -- 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

Re: [Bugme-new] [Bug 12148] New: "EHCI: BIOS handoff failed" needs to be handled better

Alan Stern — 2008-12-03T21:59:28

In the current development kernel it has been reduced to 1000. There may have been reports of systems which took at least 250 ms, maybe even more than 750 ms. (It's not easy to search for such things in the email archives...) Hence the maintainer is reluctant to make the value much lower. Me too. You'd think Intel could do a reasonable job of following its own specifications. And you'd think when they messed up, they would admit it instead of hiding behind marketing legalisms. Alan Stern -- 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

Re: bug in ehci-hcd unlink speedups

Alan Stern — 2008-12-03T21:43:48

That makes more sense. I can imagine a controller stopping the frame counter when all enabled ports are suspended. It's a reasonable power-saving technique. Still, it is annoying behavior. Do you think it can be disabled by changing a PCI config setting? After all, the kernel is capable of doing its own runtime power management without this hardware assistance. If nothing else works, we can always fall back on taking the timestamps from the kernel's clock instead of the frame counter. It might be slightly less efficient but nobody would notice. Alan Stern -- 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

Re: Order of /sys creation vs. uevent delivery

Kay Sievers — 2008-12-03T21:27:13

Looks useful in general, and we should do it if the following is not better for some reason. We may want to check if we can instead extend the already implemented notifier_call_chain() hooks which currently do: BUS_NOTIFY_ADD_DEVICE BUS_NOTIFY_DEL_DEVICE BUS_NOTIFY_BOUND_DRIVER BUS_NOTIFY_UNBIND_DRIVER It's a pretty flexible and generic infrastructure, which can have multiple "listeners", which might be nice in some cases. Would that work for usb to subscribe to the events that way, if we add the possible missing types and calls? Thanks, Kay -- 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

Re: Order of /sys creation vs. uevent delivery

Alan Stern — 2008-12-03T20:56:13

And here it is! The patch below is written for 2.6.27.4, so it should apply (perhaps with some fine adjustments) to any 2.6.27 kernel. Does this eliminate your problems? Kay, what do you think of the changes in the patch's first two files? I'll probably end up submitting that part separately from the rest. Alan Stern Index: 2.6.27.4/include/linux/device.h =================================================================== --- 2.6.27.4.orig/include/linux/device.h +++ 2.6.27.4/include/linux/device.h < at >< at > -276,6 +276,9 < at >< at > struct device_type { int (*suspend)(struct device *dev, pm_message_t state); int (*resume)(struct device *dev); +int (*add_callback)(struct device *dev); +void (*del_callback)(struct device *dev); + struct pm_ops *pm; }; Index: 2.6.27.4/drivers/base/core.c =================================================================== --- 2.6.27.4.orig/drivers/base/core.c +++ 2.6.27.4/drivers/base/core.c < at >< at > -917,6 +917,12 < at >< at > int device_add(struct device *dev) if (error) goto DP

[PATCH] Adding Ewert Energy System's CANdapter PID to FTDI_SIO Driver

Andrew Ewert — 2008-12-03T19:50:30

Hi all, I hope this is the right place to post this patch, please let me know where I should post it if it isn't or if I need to do something else. The following patch adds in the USB PID for Ewert Energy System's CANdapter device (CANBUS to USB-Serial which uses the FTDI 245R chipset) to the ftdi_sio device driver. The patch was tested successfully on Linux kernel 2.6.27 under Ubuntu. diff -uprN -X linux-2.6.27-vanilla/Documentation/dontdiff linux-2.6.27-vanilla/drivers/usb/serial/ftdi_sio.c /usr/src/linux-2.6.27/drivers/usb/serial/ftdi_sio.c --- linux-2.6.27-vanilla/drivers/usb/serial/ftdi_sio.c 2008-10-09 17:13:53.000000000 -0500 +++ /usr/src/linux-2.6.27/drivers/usb/serial/ftdi_sio.c 2008-12-02 10:06:48.000000000 -0600 < at >< at > -143,6 +143,7 < at >< at > static struct ftdi_sio_quirk ftdi_HE_TIR static struct usb_device_id id_table_combined [] = { { USB_DEVICE(FTDI_VID, FTDI_AMC232_PID) }, { USB_DEVICE(FTDI_VID, FTDI_CANUSB_PID) }, + { USB_DEVICE(FTDI_VID, FTDI_CANDAPTER_PID) }, { USB_DEV

Re: Antw: Re: WG: Blocking read [gadgetfs with Kernel 2.6.27]

Alan Stern — 2008-12-03T18:21:23

Any signal that isn't blocked or ignored will interrupt the read. You can send a signal to a process using kill(2). I don't know how you send a signal to a particular thread, however. You could ask on LKML. Alan Stern -- 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

Re: [PATCH] Update comment re. when sysfs files are created

Alan Stern — 2008-12-03T17:31:27

Never mind. I'll change the comment as part of the new create-all-sysfs-files-before-sending-uevent patch. Alan Stern -- 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

Re: [PATCH 3/3] MUSB : Fix for STALL handling in musb gadget code

Sergei Shtylyov — 2008-12-03T17:13:19

If EP is busy, we have even less reason to do a giveback. This is not a real fix, just pallialtive. Actually, whether a STALL token has been sent or not shouldn't play any role in giving back URB, so the fragment being pacthed is just totally wrong. Other drivers just don't allow EP that is still active to be halted, and this driver should do the same. What this has to do with STALL handling? WBR, Sergei -- 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

Re: [PATCH 3/3] MUSB : Fix for STALL handling in musb gadget code

Sergei Shtylyov — 2008-12-03T17:07:21

AFAIK, this code is partly authored by MontaVista. [...] NAK this part. The STALL handling is totally insane in this driver and this is a palliatve, not a fix. I'm hoping to post a real fix RSN. WBR, Sergei -- 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

Re: pl2303 - pl2303_open - failed submitting interrupt urb, error-28

Greg KH — 2008-12-03T15:47:25

I would suggest using a USB 1.1 hub instead if you have to use this kind of hardware set up. I think the core is just not able to schedule so many interrupt urbs with such a setup, running USB 1.1 devices behind a USB 2.0 hub like this is a very difficult thing to do. Sorry I don't have a better solution. thanks, greg k-h -- 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

Re: [Bugme-new] [Bug 12148] New: "EHCI: BIOS handoff failed" needsto be handled better

Greg KH — 2008-12-03T15:44:00

Does the same problem happen on 2.6.28-rc releases? Why are you doing this? That's not a good idea. In fact, it's probably the problem here. Yes, you told the BIOS to keep the USB controller, don't do that :) What happens if you change that BIOS option? -- 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

Re: [PATCH 3/3] MUSB : Fix for STALL handling in musb gadget code

Felipe Balbi — 2008-12-03T14:57:48

So it only supports mode1 for TX.. that's not really useful as most of the time our boards will be acting as gadget :-p That also breaks my plans of using only mode1 and pio for the last short packet :-s Yeah, I saw that. Cool, I'll queue it then for post 2.6.29

RE: [PATCH 3/3] MUSB : Fix for STALL handling in musb gadget code

Subbrathnam, Swaminathan — 2008-12-03T14:16:46

Balbi, As per CPPI DMA spec for TX we need to configure the DMA in MODE1 and for RX we need to configure the DMA in mode 0. This is what this patch does and only impacts CPPI DMA handling and not the generic code. This change is done within "#elif defined(CONFIG_USB_TI_CPPI_DMA)" directive. This change has been validated over the last 3 years based on 2.6.10 kernel and hence is pretty stable to take it in. On the OMAP platform I understand the definitions of mode 0/1 is different compared to that of CPPI DMA. I am testing these patches on the DaVinci GIT kernel at my end on the DM644x EVM the same would apply to DM355. Appreciate the feedback. Thanks. Regards Swami -----Original Message----- From: Felipe Balbi [mailto:felipe.balbi-xNZwKgViW5gAvxtiuMwx3w< at >public.gmane.org] Sent: Wednesday, December 03, 2008 7:35 PM To: Subbrathnam, Swaminathan Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org; felipe.balbi-xNZwKgViW5gAvxtiuMwx3w< at >public.gmane.org; davinci-linux-open-source-VycZQUHpC/PFrs

Re: [PATCH 3/3] MUSB : Fix for STALL handling in musb gadget code

Felipe Balbi — 2008-12-03T14:05:29

does cppi_dma already have support for mode1 dma ? I can't see this support in cppi_dma.c. Unfortunately I don't have (yet) any davinci board for testing this so I can't say it'll work or not for cppi_dma. this makes sense, but i'll ask you to hold on a bit on this patch since I'm cleaning up dma handling on musb. You can see it on my experimental branch at [1]. I got mode1 dma working for inventra_dma, as it's not enough, I'm not pushing those patches yet. Wanna get tusb and cppi working as well before pushing those patches. Anyways, be sure enabling mode1 dma on that TX path doesn't break anything. Leave testusb running for at least 2 days, then you resend this patch with testusb results. If everything is fine, I can queue this one and change my experimental patches for mode1 dma ;-)