Re: [RFC ebeam PATCH v2 3/3] input: misc: New USB eBeam input driver.
On Fri, 3 Aug 2012, Yann Cantin wrote:
> >> +#include
> >
> > As this driver is not a HID bus driver, why do you need this include?
>
> Cinder, removed
>
> >> +#define DRIVER_VERSION"v0.7"
> >
> > I don't think we need to be tracking driver versions for newly submitted
> > drivers, git is much better at tracking changes.
>
> Old habit, removed.
>
> >> + u16 X, Y; /* raw coordinates */
> >> + int x, y; /* computed coordinates */
> >
> > X,x being different fields seems confusing to me. How about, let's say, x,
> > raw_x?
>
> Done.
>
> >> +DEVICE_H_ATTR(1);
> >> +DEVICE_H_ATTR(2);
> >> +DEVICE_H_ATTR(3);
> >> +DEVICE_H_ATTR(4);
> >> +DEVICE_H_ATTR(5);
> >> +DEVICE_H_ATTR(6);
> >> +DEVICE_H_ATTR(7);
> >> +DEVICE_H_ATTR(8);
> >> +DEVICE_H_ATTR(9);
> >
> > You are adding a number of sysfs files. If they are really necessary,
> > you'll probably need to document those in Documentation/ABI.
>
> Will do, in testing i suppose.
>
> BTW : The driver need lot of parameters to be passed from user-space
> calibration
> tool. The best way to do it isn't decided yet : one sysfs file per parameter,
> or
> one sysfs file for all, with a big sscanf parsing. Any idea ?
Sysfs always had a rule one value per file, so please stick to that.
> >> + strlcat(ebeam->name, ")", sizeof(ebeam->name));
> >
> > I'd suggest checking the length, making sure that you don't overflow the
> > ->name buffer.
>
> Something like this ? :
>
> if (strlcat(ebeam->name, ")", sizeof(ebeam->name))>=sizeof(ebeam->name)) {
> // overflowed, closing ) anyway
> ebeam->name[sizeof(ebeam->name)-2] = ')';
Some variation on that, yes.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG Report] BUG: unable to handle kernel NULL pointer dereference at
Hi all, I'm using mainline upstream 3.6.0-rc1 compiled based on Fedora-16. When I unplug my mobile usb card, I hit this: [ 247.017258] BUG: unable to handle kernel NULL pointer dereference at (null) [ 247.017378] IP: [] stop_read_write_urbs+0x3f/0x90 [usb_wwan] [ 247.017484] PGD 0 [ 247.017518] Oops: [#1] SMP [ 247.017572] Modules linked in: cdc_ether usbnet mii option usb_wwan usb_storage tcp_lp fuse lockd rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ext3 jbd arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant btusb bluetooth i915 snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd_page_alloc thinkpad_acpi snd iwlwifi cfg80211 soundcore e1000e rfkill wmi drm_kms_helper drm i2c_i801 i2c_algo_bit i2c_core lpc_ich mfd_core pcspkr coretemp tpm_tis tpm tpm_bios joydev uinput crc32c_intel ghash_clmulni_intel sunrpc microcode video sdhci_pci sdhci mmc_core [ 247.018728] CPU 0 [ 247.018762] Pid: 34, comm: khubd Not tainted 3.6.0-rc1+ #2 LENOVO 4291HA6/4291HA6 [ 247.018860] RIP: 0010:[] [] stop_read_write_urbs+0x3f/0x90 [usb_wwan] [ 247.018991] RSP: 0018:88021441dba0 EFLAGS: 00010286 [ 247.019080] RAX: RBX: RCX: dead00200200 [ 247.019212] RDX: 8801f6225228 RSI: 8801f190f678 RDI: 8801f6224a10 [ 247.019350] RBP: 88021441dbd0 R08: 8801f6224a28 R09: ea0007c66800 [ 247.019489] R10: 812ceb05 R11: 5347203a30425355 R12: 880212a1a780 [ 247.019629] R13: 880212a1a780 R14: R15: [ 247.019771] FS: () GS:88021e20() knlGS: [ 247.019928] CS: 0010 DS: ES: CR0: 8005003b [ 247.020045] CR2: CR3: 0002129ed000 CR4: 000407f0 [ 247.020184] DR0: DR1: DR2: [ 247.020309] DR3: DR6: 0ff0 DR7: 0400 [ 247.020450] Process khubd (pid: 34, threadinfo 88021441c000, task 880214b25c00) [ 247.020605] Stack: [ 247.020649] 88021441dbb0 880212a1a780 8801f61fb830 8801f6224800 [ 247.020822] 0001 880212a1a788 88021441dbe0 a03bf2de [ 247.020991] 88021441dc30 81463b8d 8801fab7a448 8801f6220800 [ 247.021163] Call Trace: [ 247.021228] [] usb_wwan_disconnect+0xe/0x10 [usb_wwan] [ 247.021370] [] usb_serial_disconnect+0xdd/0x130 [ 247.021506] [] usb_unbind_interface+0x5d/0x1b0 [ 247.021635] [] __device_release_driver+0x7c/0xe0 [ 247.021739] [] device_release_driver+0x2c/0x40 [ 247.021822] [] bus_remove_device+0xe3/0x150 [ 247.021900] [] device_del+0x120/0x1b0 [ 247.021974] [] usb_disable_device+0xb0/0x280 [ 247.022066] [] usb_disconnect+0x9d/0x140 [ 247.022143] [] hub_thread+0xba1/0x1720 [ 247.022218] [] ? remove_wait_queue+0x50/0x50 [ 247.022297] [] ? usb_remote_wakeup+0x70/0x70 [ 247.022375] [] kthread+0x93/0xa0 [ 247.022443] [] kernel_thread_helper+0x4/0x10 [ 247.022520] [] ? flush_kthread_worker+0xb0/0xb0 [ 247.022601] [] ? gs_change+0x13/0x13 [ 247.022667] Code: 66 90 80 7f 1a 00 49 89 fd 74 5a 49 89 fc 31 db 0f 1f 40 00 49 8b 7c 24 20 45 31 f6 48 81 c7 10 02 00 00 e8 24 25 ff e0 49 89 c7 <4b> 8b 3c 37 49 83 c6 08 e8 a4 e0 06 e1 49 83 fe 20 75 ed 45 30 [ 247.023188] RIP [] stop_read_write_urbs+0x3f/0x90 [usb_wwan] [ 247.026877] RSP [ 247.030500] CR2: [ 247.055642] ---[ end trace d12afd8ebf250ae7 ]--- thanks, liubo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: hcd: mark controller's suspend routine as async
Host controller's suspend should be executed later than root hub's, or the hang may occur when root hub try to visit some registers but host controller's suspend close the related clocks. Mark controller's suspend as async can make sure it is executed later than root hub's as host controller is the parent of root hub. Signed-off-by: Peter Chen --- drivers/usb/core/hcd.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index bc84106..29a708a 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -2512,6 +2512,14 @@ int usb_add_hcd(struct usb_hcd *hcd, * controllers should always be enabled for remote wakeup. */ device_wakeup_enable(hcd->self.controller); + /* +* Host controller's suspend should be executed later than root hub's, +* or the hang may occur when root hub try to visit some registers +* but host controller's suspend close the related clocks. +* Mark controller's suspend as async can make sure it is executed +* later than root hub's as controller is the parent of root hub. +*/ + device_enable_async_suspend(hcd->self.controller); return retval; error_create_attr_group: -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG Report] BUG: unable to handle kernel NULL pointer dereference at
Liu Bo writes: > I'm using mainline upstream 3.6.0-rc1 compiled based on Fedora-16. > > When I unplug my mobile usb card, I hit this: > > [ 247.017258] BUG: unable to handle kernel NULL pointer dereference at > (null) > [ 247.017378] IP: [] stop_read_write_urbs+0x3f/0x90 > [usb_wwan] Thanks for reporting. This should be fixed by a1028f0 usb: usb_wwan: replace release and disconnect with a port_remove hook currently in the usb tree, and hopefully going into the next -rc Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB host isochronous transfer broken
Hi, I need some help debugging a USB transfer problem on my raspberry pi. I know this is not a mainstream kernel issue but I would be glad if someone here can help me understand and debug the problem. The problem is that the DVB Transport stream recorded from a usb DVB stick (cinergy htc stick) attached to a usb hub which is attached to the raspberry pi is broken. I use the latest media_build from linuxtv.org against a 3.1.9 raspberry pi kernel. The same drivers from the media_build work perfectly with a 3.1.9 kernel on my thinkpad. [ 126.162705] tda18271: performing RF tracking filter calibration [ 128.056572] tda18271: RF tracking filter calibration complete [ 128.057855] em28xx #0/2-dvb: Using 5 buffers each with 64 x 940 bytes [ 129.052712] em28xx #0/2-dvb: ISO ERROR COUNT: 1. [ 129.052743] em28xx #0/2-dvb: URB packet 0, status -4001 [Unknown]. [ 129.581352] em28xx #0/2-dvb: ISO ERROR COUNT: 1. [ 129.581384] em28xx #0/2-dvb: URB packet 0, status -4001 [Unknown]. [ 129.872090] em28xx #0/2-dvb: ISO ERROR COUNT: 1. [ 129.872122] em28xx #0/2-dvb: URB packet 0, status -4001 [Unknown]. [ 129.969224] em28xx #0/2-dvb: ISO ERROR COUNT: 1. [ 129.969258] em28xx #0/2-dvb: URB packet 44, status -4001 [Unknown]. My assumption is that the isochronous transfer is broken for the usb host driver. The error code is defined in: drivers/usb/host/dwc_common_port/dwc_os.h:#define DWC_E_NO_STREAM_RES 4001 which is caused by a DWC_OTG_HC_XFER_FRAME_OVERRUN in the URB: dwc_otg/dwc_otg_hcd_intr.c:753: frame_desc->status = -DWC_E_NO_STREAM_RES; I'm a bit lost since I do not have any USB specific knowledge but I really want to get the DVB Stick running ;) Is there anything you recommend me to check/test/read? What can I test/check? Is there a test tool for testing the isochronous transfer for a host? (I looked at the usbtest driver in the kernel, but I can't figure out how to test isochronous transfer with it) Thanks for your help! Cheers, Ruben -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG Report] BUG: unable to handle kernel NULL pointer dereference at
On 08/13/2012 06:01 PM, Bjørn Mork wrote: > Liu Bo writes: > >> I'm using mainline upstream 3.6.0-rc1 compiled based on Fedora-16. >> >> When I unplug my mobile usb card, I hit this: >> >> [ 247.017258] BUG: unable to handle kernel NULL pointer dereference at >> (null) >> [ 247.017378] IP: [] stop_read_write_urbs+0x3f/0x90 >> [usb_wwan] > > Thanks for reporting. This should be fixed by > > a1028f0 usb: usb_wwan: replace release and disconnect with a port_remove hook > > currently in the usb tree, and hopefully going into the next -rc > > > > Bjørn > okay, I'll test it later :) Thanks for the quick fix, Bjørn. thanks, liubo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 0/3] qmi_wwan: simplify device matching and add a few new devices
Bjørn Mork writes: > The home cooked whitelisting code can be removed now that > the USB core supports interface number matching. > > The second patch adds a few new devices. > > The third patch improves device list readability by using > existing macros where possible. > > I hope this can go in 3.6-rc2/3. The series is based on > the current net/master (commit 2359a476) Just an additional afterthought: Please do not apply this as it is to "net-next" if you decide it is inappropriate for "net". New devices will be added to the driver during the 3.6 cycle whether or not the probing changes are accepted. This will result in unnecessary merge conflicts. I'll submit a new version of the patch set for "net-next" when we have a better idea of what the device list looks like at the beginning of the 3.7 cycle. But I am still hoping this is accepted for "net", although I obviously screwed up choosing strategy to avoid net/usb merge conflicts. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] usb: musb: convert the request_irq of NIrq to devm_*
Convert the request_irq to devm_request_irq.
Also fixes the case where the in the function musb_init_controller
free_irq(called from musb_free) is called before it is allocated.
Signed-off-by: Shubhrajyoti D
---
drivers/usb/musb/musb_core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index dd24f96..b5cf52a 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1834,7 +1834,6 @@ static void musb_free(struct musb *musb)
if (musb->nIrq >= 0) {
if (musb->irq_wake)
disable_irq_wake(musb->nIrq);
- free_irq(musb->nIrq, musb);
}
if (is_dma_capable() && musb->dma_controller) {
struct dma_controller *c = musb->dma_controller;
@@ -1947,7 +1946,8 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
INIT_WORK(&musb->irq_work, musb_irq_work);
/* attach to the IRQ */
- if (request_irq(nIrq, musb->isr, 0, dev_name(dev), musb)) {
+ if (devm_request_irq(musb->controller, nIrq, musb->isr, 0,
+ dev_name(dev), musb)) {
dev_err(dev, "request_irq %d failed!\n", nIrq);
status = -ENODEV;
goto fail3;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: hcd: mark controller's suspend routine as async
On Mon, 13 Aug 2012, Peter Chen wrote: > Host controller's suspend should be executed later than root hub's, > or the hang may occur when root hub try to visit some registers > but host controller's suspend close the related clocks. Have you ever seen this happen? It should not be possible, because the PM core is careful not to suspend a parent before its child devices. > Mark controller's suspend as async can make sure it is executed > later than root hub's as host controller is the parent of root hub. We want to be careful about this sort of thing. Most of the async suspend notations are for devices on a particular kind of bus, but the notation you want to add would apply to all host controllers on any bus. If you really do see a host controller suspending before its root hub, this indicates there is a bug in the PM core. The bug should be fixed; you shouldn't ignore it by marking all host controllers for async suspend. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] can: kvaser_usb: Add support for Kvaser CAN/USB devices
This driver provides support for several Kvaser CAN/USB devices. Such kind of devices supports up to three CAN network interfaces. It has been tested with a Kvaser USB Leaf Light (one network interface) connected to a pch_can interface. The firmware version of the Kvaser device was 2.5.205. List of Kvaser devices supported by the driver: - Kvaser Leaf prototype (P010v2 and v3) - Kvaser Leaf Light (P010v3) - Kvaser Leaf Professional HS - Kvaser Leaf SemiPro HS - Kvaser Leaf Professional LS - Kvaser Leaf Professional SWC - Kvaser Leaf Professional LIN - Kvaser Leaf SemiPro LS - Kvaser Leaf SemiPro SWC - Kvaser Memorator II, Prototype - Kvaser Memorator II HS/HS - Kvaser USBcan Professional HS/HS - Kvaser Leaf Light GI - Kvaser Leaf Professional HS (OBD-II connector) - Kvaser Memorator Professional HS/LS - Kvaser Leaf Light "China" - Kvaser BlackBird SemiPro - Kvaser OEM Mercury - Kvaser OEM Leaf - Kvaser USBcan R Signed-off-by: Olivier Sobrie --- Changes since v2: - update of error handling - add method do_get_berr_counter if hardware support it - fix race condition in probe function - ... Here is the behavior in case of errors: Case 1: restart-ms 0 + short-circuit t0: short-circuit + cansend can1 123@1122 (016.731173) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.09) can1 2088 [8] 00 00 D0 00 00 00 00 00 ERRORFRAME (000.10) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.05) can1 2088 [8] 00 00 D0 00 00 00 00 00 ERRORFRAME (000.06) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.04) can1 2088 [8] 00 00 D0 00 00 00 00 00 ERRORFRAME (000.07) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.07) can1 2088 [8] 00 00 D0 00 00 00 00 00 ERRORFRAME (000.07) can1 208C [8] 00 30 90 00 00 00 00 00 ERRORFRAME (000.001062) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.11) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.08) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.07) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000978) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.07) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.09) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.08) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.001108) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.07) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.07) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.06) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.07) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.001082) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.46) can1 20C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME t1: ip link set can1 type can restart: (125.211773) can1 2100 [8] 00 00 00 00 00 00 00 00 ERRORFRAME (000.020207) can1 2088 [8] 00 00 40 00 00 00 00 00 ERRORFRAME Case 2: short-circuit + restart-ms > 0 t0: short-circuit + cansend can1 123@1122 (006.079601) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.91) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.83) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.83) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.82) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.86) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.83) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.82) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.83) can1 208C [8] 00 30 90 00 00 00 00 00 ERRORFRAME (000.000352) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000103) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000106) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000105) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000808) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000125) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000110) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000108) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000106) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000110) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000560) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000104) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000104) can1 2088 [8] 00 00 90 00 00 00 00 00 ERRORFRAME (000.000106) can1 2088 [8] 00
Re: DesignWare USB OTG dwc_otg issues with high-speed hubs
On Sat, Aug 11, 2012 at 12:13:58AM +0400, Paul Fertser wrote: > Hi Felipe, > > On Fri, Aug 10, 2012 at 10:39:52PM +0300, Felipe Balbi wrote: > > On Fri, Aug 10, 2012 at 10:35:20PM +0400, Paul Fertser wrote: > > > I'm using an RT3052F device (DIR-620 SOHO wifi router) with current > > > OpenWrt trunk and its USB port is handled by the dwc_otg driver. The > > > source is available from their repository: > > > https://dev.openwrt.org/browser/trunk/target/linux/ramips/files/drivers/usb/dwc_otg > > > > there's no such driver in mainline kernel. We cannot support you. You > > need to ask help from openwrt project. > > Well, sorry, but i'm not sure that's entirely correct. People involved Will you ask about linux kernel on a BSD mailing list just because some linux guys hang out there ? > in writing and using that driver are quite possibly hanging around > here. I know this is not an upstream driver (in fact it was ported > from Ralink's SDK by Layne Edwards) and i understand that vendor Since Layne's in Cc, you could very well post to openwrt mailing list and Cc him, just like you did here ;-) > drivers usually suck big time. > > OTOH, vendor drivers are quite often a valuable source of the > information and having a link to a version that works on current > kernels might be beneficial as one can do a side-by-side comparison > and testing. Still mate, if it isn't in mainline, it's very unlikely anyone will be able to help you. You're much better off stiking to the support channels of whoever provided you the kernel you're using. > Of course i would appreciate someone sharing his ideas about another, > proper upstream driver that is usable on an RT3052 target. Samsumg Exynos platforms use this same IP and their s3c_hsotg.c driver is being cleaned up so it can be re-used by other platforms. They need help, however. If you want to help, you're very much welcome. The effort is still in early phase and there's lots to be done. > I hope i put it clearly enough so that a person not interested in > non-upstream code won't waste his time reading this thread. I hope > this is enough of an excuse for CCing the list. If not, please let me > know. If you don't want to waste upstream developer's time, then don't post non-upstream related issues to the upstream mailing list ;-) -- balbi signature.asc Description: Digital signature
question concerning finish_port_resume()
Hi, in finish_port_resume() usb_get_status() is always done and the result evaluated even in the case of reset_resume. Is this efficient? If a device has been reset, remote wakeup must be disabled. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
mxs-phy on i.MX233 not enumerating
We're trying to get USB host mode working on a Freescale i.MX233. I'm using a chumby hacker board, but there are several people trying on an OlinuXino board as well. We're running into a problem where every time the root hub is detected, it's disconnected. This results in kernel messages such as: [ 66.41] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.63] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 66.85] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 67.07] hub 1-0:1.0: unable to enumerate USB device on port 1 It looks like we're running into this chip issue described in the i.MX233 reference manual: >For host mode, enables high-speed disconnect detector. This signal >allows the override of enabling the detection that is normally done in >the UTMI controller. The UTMI controller enables this circuit whenever >the host sends a start-of-frame packet. Due to a on chip issue (Errata >#2791), software must pay attention to when to assert the >ENHOSTDISCONDETECT bit in HW_USBPHY_CTRL register: >1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during high speed >host mode. >2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during the reset >and speed negotiation period. >3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during host >suspend/resume sequence. We suspect this because we can get it to detect a USB device when it first boots by applying the following patch: diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c index c1a67cb..23eeae6 100644 --- a/drivers/usb/otg/mxs-phy.c +++ b/drivers/usb/otg/mxs-phy.c @@ -81,8 +81,6 @@ static int mxs_phy_on_connect(struct usb_phy *phy, int port) dev_dbg(phy->dev, "Connect on port %d\n", port); mxs_phy_hw_init(to_mxs_phy(phy)); - writel_relaxed(BM_USBPHY_CTRL_ENHOSTDISCONDETECT, - phy->io_priv + HW_USBPHY_CTRL_SET); return 0; } On platforms where a hub is connected to the device, this works fine, as the hub will never be connected and we can rely on disconnect messages coming from the downstream hub. But on boards where USB devices may be connected directly to the processor, only the first device connected to the system will work. I think the controller will need to be modified to detect whether it's running on an i.MX233 or not, and to call the PHY to re-enable disconnect detection if it sees a hub successfully added. In this case, it's a ci13xxx. Where would the best place be to add this callback? Can anyone at Freescale comment on this particular chip quirk? I don't see #2791 in the chip errata document. And is this quirk present on any other devices supported by the mxs_phy driver, or is it purely an i.MX233-specific quirk? -- Sean Cross -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Infinite looping in omap2430.c USB driver
Hi,
On Mon, Aug 13, 2012 at 12:34:53PM +1000, NeilBrown wrote:
> On Thu, 9 Aug 2012 14:15:51 +0300 Felipe Balbi wrote:
>
>
> > hehe, that's nasty. Please send a patch converting to a try count and a
> > udelay_range(), or something.
> >
>
> how's this?
>
> Thanks,
> NeilBrown
>
>
> From: NeilBrown
> Date: Mon, 13 Aug 2012 12:32:58 +1000
> Subject: [PATCH] omap2430: don't loop indefinitely in interrupt.
>
> When called during resume_irqs, omap2430_musb_set_vbus() is run with
> interrupts disabled, In that case 'jiffies' never changes so the loop
> can loop forever.
>
> So impose a maximum loop count and add an 'mdelay' to ensure we wait
> a reasonable amount of time for bit to be cleared.
>
> This fixes a hang on resume.
>
> Signed-of-by: NeilBrown
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index c7785e8..8a93381 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include "musb_core.h"
> #include "omap2430.h"
> @@ -145,6 +146,7 @@ static void omap2430_musb_set_vbus(struct musb *musb, int
> is_on)
>
> if (is_on) {
> if (musb->xceiv->state == OTG_STATE_A_IDLE) {
> + int loops = 100;
> /* start the session */
> devctl |= MUSB_DEVCTL_SESSION;
> musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
> @@ -154,9 +156,11 @@ static void omap2430_musb_set_vbus(struct musb *musb,
> int is_on)
>*/
> while (musb_readb(musb->mregs, MUSB_DEVCTL) & 0x80) {
>
> + mdelay(5);
I would prefer udelay_range() as it will let scheduler group timers.
Something like:
udelay_range(3000, 5000);
should do, I gues...
--
balbi
signature.asc
Description: Digital signature
Re: USB host isochronous transfer broken
On Mon, Aug 13, 2012 at 12:01:52PM +0200, Ruben Jenster wrote: > Hi, > > I need some help debugging a USB transfer problem on my raspberry pi. > I know this is not a mainstream kernel issue but I would be glad if someone > here can > help me understand and debug the problem. > > The problem is that the DVB Transport stream recorded from a usb DVB stick > (cinergy htc stick) > attached to a usb hub which is attached to the raspberry pi is broken. > I use the latest media_build from linuxtv.org against a 3.1.9 raspberry pi > kernel. > The same drivers from the media_build work perfectly with a 3.1.9 kernel on > my thinkpad. > > [ 126.162705] tda18271: performing RF tracking filter calibration > [ 128.056572] tda18271: RF tracking filter calibration complete > [ 128.057855] em28xx #0/2-dvb: Using 5 buffers each with 64 x 940 bytes > [ 129.052712] em28xx #0/2-dvb: ISO ERROR COUNT: 1. > [ 129.052743] em28xx #0/2-dvb: URB packet 0, status -4001 [Unknown]. > [ 129.581352] em28xx #0/2-dvb: ISO ERROR COUNT: 1. > [ 129.581384] em28xx #0/2-dvb: URB packet 0, status -4001 [Unknown]. > [ 129.872090] em28xx #0/2-dvb: ISO ERROR COUNT: 1. > [ 129.872122] em28xx #0/2-dvb: URB packet 0, status -4001 [Unknown]. > [ 129.969224] em28xx #0/2-dvb: ISO ERROR COUNT: 1. > [ 129.969258] em28xx #0/2-dvb: URB packet 44, status -4001 [Unknown]. > > My assumption is that the isochronous transfer is broken for the usb host > driver. After reading the code for the USB host driver for this hardware, and reading the hardware data sheet, I'm amazed that any USB devices work on this platform :) I think you are right in that isoc just doesn't work on the codebase you are trying to use, but I would try asking on the raspberry-pi kernel mailing list to see if there are any updates that you can try out for newer versions of the kernel and drivers, as I think a lot of work is going on in this area last time I looked. best of luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Prolem of setting DeviceRemovable according ACPI information
Hi all: I am trying to implement patch of setting DeviceRemovable according ACPI information. The DeviceRemovable is set in hcd driver *_hub_descriptor(e.g ehci_hub_descriptor()). But these functions just have struct usb_hcd or hcd specific struct(e.g struct xhci_hcd) and struct usb_hub_descriptor point as parameter. There is no way to get the root hub's struct usb_device which can be used to find ports'device and then get ports' acpi handle and information. A bridge between usb_hcd and root hub's usb_device is needed. I have a proposal of add root hub's struct usb_device point into the struct usb_hcd. Does this make sense or is there other solutions? Thanks. Best Regards Tianyu Lan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question concerning finish_port_resume()
On Mon, 13 Aug 2012, Oliver Neukum wrote: > Hi, > > in finish_port_resume() usb_get_status() is always done and the result > evaluated even in the case of reset_resume. Is this efficient? If a device > has been reset, remote wakeup must be disabled. Checking the remote wakeup setting is not the only purpose of the usb_get_status() call. It also helps to verify that the device is still working properly. Of course, in the case of reset-resume we already know that the device must be working (because we have checked the descriptors). So maybe it makes sense to get rid of usb_get_status() in this case. On the other hand, resetting the device is a lengthy procedure and usb_get_status() doesn't increase the length by all that much. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Prolem of setting DeviceRemovable according ACPI information
On Mon, 13 Aug 2012, Lan, Tianyu wrote: > Hi all: > I am trying to implement patch of setting DeviceRemovable > according ACPI information. > The DeviceRemovable is set in hcd driver *_hub_descriptor(e.g > ehci_hub_descriptor()). But these > functions just have struct usb_hcd or hcd specific struct(e.g struct > xhci_hcd) and struct usb_hub_descriptor > point as parameter. There is no way to get the root hub's struct usb_device > which can be used to find > ports'device and then get ports' acpi handle and information. A bridge > between usb_hcd and root hub's > usb_device is needed. I have a proposal of add root hub's struct usb_device > point into the struct usb_hcd. > Does this make sense or is there other solutions? Thanks. hcd->bus.root_hub. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbserial issue
Hi, I discovered the problem. I am using Openwrt and I was missing the module usb-serial-option. Using it everything works fine. The device modules and parameters are loaded and ttyUSB* are created. Thanks for all the help, Guilherme On Fri, Jul 20, 2012 at 3:47 AM, Bjørn Mork wrote: > Guilherme Bedin writes: > >> Thanks for explanation on how things work. >> The problem is if I don't pass the vendor and prodId the 3g modem is >> detect as an USB mass storage. Even after using usb_modeswitch >> >> usb_modeswitch -default-vendor 0x19d2 -default-product 0×2000 >> -target-vendor 0x19d2 -target-product 0×0031 -message-endpoint 0×01 >> -message-content 555342431234567 >> 820008c85010101180101010101 >> >> I am running on: >> Linux OpenWrt 3.3.8 #1 Mon Jul 9 20:09:35 MSK 2012 mips GNU/Linux >> >> With: >> >> Modem 3g >> >> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 >> P: Vendor=19d2 ProdID=0031 Rev= 0.00 > > That device was added to the option driver almost 3 years ago, so the > driver support should be OK. But you might be interested in this > recent discussion of modeswitch problems with exactly that device: > > http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=951 > > I suspect you are hit by the same problem, causing usb_modeswitch to > switch the modem twice. > > All thanks to the genious in ZTE who is responsible for reusing the same > device ID for switched and unswitched mode in different devices. So > 19d2:0031 is the target ID for some devices like yours, but it is the > default unswitched ID for others... Thank you, ZTE. That's just brilliant. > > But anyway, try upgrading to the latest usb_modeswitch_data. If that > doesn't work, enable usb_modeswitch logging to verify that the problem > really is double switching. Then look at > /lib/udev/rules.d/40-usb_modeswitch.rules > and see if it's possible to tweak the rules to avoid this. > > Or just create an empty 19d2:0031 config to disable the second switch. > But that is only a local workaround, since there are devices with this > ID shich need switching. > > > Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] xhci: Fix a logical vs bitwise AND bug
The intent was to test whether the flag was set.
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c59d5b5..617b0a7 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -659,7 +659,7 @@ void xhci_shutdown(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- if (xhci->quirks && XHCI_SPURIOUS_REBOOT)
+ if (xhci->quirks & XHCI_SPURIOUS_REBOOT)
usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
spin_lock_irq(&xhci->lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mxs-phy on i.MX233 not enumerating
On 8/13/12, Sean Cross wrote: > We're trying to get USB host mode working on a Freescale i.MX233. I'm > using > a chumby hacker board, but there are several people trying on an OlinuXino > board as well. We're running into a problem where every time the root hub > is detected, it's disconnected. This results in kernel messages such as: > > [ 66.41] hub 1-0:1.0: unable to enumerate USB device on port 1 > [ 66.63] hub 1-0:1.0: unable to enumerate USB device on port 1 > [ 66.85] hub 1-0:1.0: unable to enumerate USB device on port 1 > [ 67.07] hub 1-0:1.0: unable to enumerate USB device on port 1 > > It looks like we're running into this chip issue described in the i.MX233 > reference manual: > >>For host mode, enables high-speed disconnect detector. This signal >>allows the override of enabling the detection that is normally done in >>the UTMI controller. The UTMI controller enables this circuit whenever >>the host sends a start-of-frame packet. Due to a on chip issue (Errata >>#2791), software must pay attention to when to assert the >>ENHOSTDISCONDETECT bit in HW_USBPHY_CTRL register: >>1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during high speed >>host mode. >>2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during the reset >>and speed negotiation period. >>3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during host >>suspend/resume sequence. > > We suspect this because we can get it to detect a USB device when it first > boots by applying the following patch: > > diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c > index c1a67cb..23eeae6 100644 > --- a/drivers/usb/otg/mxs-phy.c > +++ b/drivers/usb/otg/mxs-phy.c > @@ -81,8 +81,6 @@ static int mxs_phy_on_connect(struct usb_phy *phy, int > port) > dev_dbg(phy->dev, "Connect on port %d\n", port); > > mxs_phy_hw_init(to_mxs_phy(phy)); > - writel_relaxed(BM_USBPHY_CTRL_ENHOSTDISCONDETECT, > - phy->io_priv + HW_USBPHY_CTRL_SET); > > return 0; > } I applied this change and it allowed a mx23-olinuxino board to detect a USB pen drive. Peter, Is this change related to this hack in FSL kernel? http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=commitdiff;h=c44dc00d2aecfcbf30336180f5ecd6a3a633545d What would be the proper way to handle HOSTDISCONDETECT so that it can work for mx23 as well? Thanks, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mxs-phy on i.MX233 not enumerating
Hi, On Mon, Aug 13, 2012 at 03:04:56PM -0300, Fabio Estevam wrote: > On 8/13/12, Sean Cross wrote: > > We're trying to get USB host mode working on a Freescale i.MX233. I'm > > using > > a chumby hacker board, but there are several people trying on an OlinuXino > > board as well. We're running into a problem where every time the root hub > > is detected, it's disconnected. This results in kernel messages such as: > > > > [ 66.41] hub 1-0:1.0: unable to enumerate USB device on port 1 > > [ 66.63] hub 1-0:1.0: unable to enumerate USB device on port 1 > > [ 66.85] hub 1-0:1.0: unable to enumerate USB device on port 1 > > [ 67.07] hub 1-0:1.0: unable to enumerate USB device on port 1 > > > > It looks like we're running into this chip issue described in the i.MX233 > > reference manual: > > > >>For host mode, enables high-speed disconnect detector. This signal > >>allows the override of enabling the detection that is normally done in > >>the UTMI controller. The UTMI controller enables this circuit whenever > >>the host sends a start-of-frame packet. Due to a on chip issue (Errata > >>#2791), software must pay attention to when to assert the > >>ENHOSTDISCONDETECT bit in HW_USBPHY_CTRL register: > >>1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during high speed > >>host mode. > >>2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during the reset > >>and speed negotiation period. > >>3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during host > >>suspend/resume sequence. > > > > We suspect this because we can get it to detect a USB device when it first > > boots by applying the following patch: > > > > diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c > > index c1a67cb..23eeae6 100644 > > --- a/drivers/usb/otg/mxs-phy.c > > +++ b/drivers/usb/otg/mxs-phy.c > > @@ -81,8 +81,6 @@ static int mxs_phy_on_connect(struct usb_phy *phy, int > > port) > > dev_dbg(phy->dev, "Connect on port %d\n", port); > > > > mxs_phy_hw_init(to_mxs_phy(phy)); > > - writel_relaxed(BM_USBPHY_CTRL_ENHOSTDISCONDETECT, > > - phy->io_priv + HW_USBPHY_CTRL_SET); > > > > return 0; > > } > > I applied this change and it allowed a mx23-olinuxino board to detect > a USB pen drive. > > Peter, > > Is this change related to this hack in FSL kernel? > http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=commitdiff;h=c44dc00d2aecfcbf30336180f5ecd6a3a633545d > > What would be the proper way to handle HOSTDISCONDETECT so that it can > work for mx23 as well? Will there be another version for this or is this final ? Won't this cause any regressions to other boards ? -- balbi signature.asc Description: Digital signature
Re: mxs-phy on i.MX233 not enumerating
On 8/13/12, Felipe Balbi wrote: > Will there be another version for this or is this final ? Won't this > cause any regressions to other boards ? The proposed patch is not meant to be a final one. We still need to figure out the proper way to handle HOSTDISCONDETECT for all i.mx SoCs, including mx23, and would like to get some feedback from the FSL guys in Cc. Thanks, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Infinite looping in omap2430.c USB driver
On Mon, 13 Aug 2012 17:32:34 +0300 Felipe Balbi wrote:
> Hi,
>
> On Mon, Aug 13, 2012 at 12:34:53PM +1000, NeilBrown wrote:
> > On Thu, 9 Aug 2012 14:15:51 +0300 Felipe Balbi wrote:
> >
> >
> > > hehe, that's nasty. Please send a patch converting to a try count and a
> > > udelay_range(), or something.
> > >
> >
> > how's this?
> >
> > Thanks,
> > NeilBrown
> >
> >
> > From: NeilBrown
> > Date: Mon, 13 Aug 2012 12:32:58 +1000
> > Subject: [PATCH] omap2430: don't loop indefinitely in interrupt.
> >
> > When called during resume_irqs, omap2430_musb_set_vbus() is run with
> > interrupts disabled, In that case 'jiffies' never changes so the loop
> > can loop forever.
> >
> > So impose a maximum loop count and add an 'mdelay' to ensure we wait
> > a reasonable amount of time for bit to be cleared.
> >
> > This fixes a hang on resume.
> >
> > Signed-of-by: NeilBrown
> >
> > diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> > index c7785e8..8a93381 100644
> > --- a/drivers/usb/musb/omap2430.c
> > +++ b/drivers/usb/musb/omap2430.c
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "musb_core.h"
> > #include "omap2430.h"
> > @@ -145,6 +146,7 @@ static void omap2430_musb_set_vbus(struct musb *musb,
> > int is_on)
> >
> > if (is_on) {
> > if (musb->xceiv->state == OTG_STATE_A_IDLE) {
> > + int loops = 100;
> > /* start the session */
> > devctl |= MUSB_DEVCTL_SESSION;
> > musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
> > @@ -154,9 +156,11 @@ static void omap2430_musb_set_vbus(struct musb *musb,
> > int is_on)
> > */
> > while (musb_readb(musb->mregs, MUSB_DEVCTL) & 0x80) {
> >
> > + mdelay(5);
>
> I would prefer udelay_range() as it will let scheduler group timers.
> Something like:
>
> udelay_range(3000, 5000);
>
> should do, I gues...
>
Except that there is no udelay_range :-(
There is a usleep_range, but that can only be used from non-atomic context
and in the problem case interrupts are disabled and a spinlock is held so we
very definitely are not in non-atomic context. If we need a delay at all, it
has to be udelay or mdelay.
If we could do this in a work function rather than directly from the
interrupt handler that would be best but I have no idea what dependencies
there are.. Would it be safe for musb_stage0_irq() to ask a workqueue to run
musb_platform_set_vbus rather than doing it directly?
NeilBrown
signature.asc
Description: PGP signature
RE: mxs-phy on i.MX233 not enumerating
> On 8/13/12, Felipe Balbi wrote: > > > Will there be another version for this or is this final ? Won't this > > cause any regressions to other boards ? > > The proposed patch is not meant to be a final one. > > We still need to figure out the proper way to handle HOSTDISCONDETECT > for all i.mx SoCs, including mx23, and would like to get some feedback > from the FSL guys in Cc. > According to IC guys, the logic of handling HOSTDISCONDETECT is the same between i.mx28 and i.mx23. > Thanks, > > Fabio Estevam
Re: mxs-phy on i.MX233 not enumerating
Dear Chen Peter-B29397, > > On 8/13/12, Felipe Balbi wrote: > > > Will there be another version for this or is this final ? Won't this > > > cause any regressions to other boards ? > > > > The proposed patch is not meant to be a final one. > > > > We still need to figure out the proper way to handle HOSTDISCONDETECT > > for all i.mx SoCs, including mx23, and would like to get some feedback > > from the FSL guys in Cc. > > According to IC guys, the logic of handling HOSTDISCONDETECT is the same > between i.mx28 and i.mx23. I recall we had issues with the discon detector on MX28, but on mx28 the chip was completely deaf (no messages in kernel log). Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mxs-phy on i.MX233 not enumerating
Peter, On 8/13/12, Chen Peter-B29397 wrote: > According to IC guys, the logic of handling HOSTDISCONDETECT is the same > between i.mx28 and i.mx23. As pointed out by Sean, on mx23 reference manual we have the following text describing HOSTDISCONDETECT: "Due to a on chip issue (Errata #2791), software must pay attention to when to assert the HOSTDISCONDETECT bit description has the following: ENHOSTDISCONDETECT bit in HW_USBPHY_CTRL register: 1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during high speed host mode. 2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during the reset and speed negotiation period. 3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT during host suspend/resume sequence." and the same is not present on mx28 reference manual. How can we make sure we are not violating the point 2 above? Thanks, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mxs-phy on i.MX233 not enumerating
Add IC guy
Best regards,
Peter Chen
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Tuesday, August 14, 2012 10:01 AM
> To: Chen Peter-B29397
> Cc: ba...@ti.com; Sean Cross; linux-usb@vger.kernel.org; Estevam Fabio-
> R49496; Zhao Richard-B20223; Shawn Guo; Marek Vasut; Li Frank-B20596
> Subject: Re: mxs-phy on i.MX233 not enumerating
>
> Peter,
>
> On 8/13/12, Chen Peter-B29397 wrote:
>
> > According to IC guys, the logic of handling HOSTDISCONDETECT is the
> same
> > between i.mx28 and i.mx23.
>
> As pointed out by Sean, on mx23 reference manual we have the following
> text describing HOSTDISCONDETECT:
>
> "Due to a on chip issue (Errata #2791), software must
> pay attention to when to assert the HOSTDISCONDETECT bit description
> has the following:
>
> ENHOSTDISCONDETECT bit in HW_USBPHY_CTRL register:
> 1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
> during high speed host mode.
> 2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
> during the reset and speed negotiation period.
> 3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
> during host suspend/resume sequence."
>
> and the same is not present on mx28 reference manual.
>
> How can we make sure we are not violating the point 2 above?
>
> Thanks,
>
> Fabio Estevam
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
RE: mxs-phy on i.MX233 not enumerating
>
> > According to IC guys, the logic of handling HOSTDISCONDETECT is the
> same
> > between i.mx28 and i.mx23.
>
> As pointed out by Sean, on mx23 reference manual we have the following
> text describing HOSTDISCONDETECT:
>
> "Due to a on chip issue (Errata #2791), software must
> pay attention to when to assert the HOSTDISCONDETECT bit description
> has the following:
>
> ENHOSTDISCONDETECT bit in HW_USBPHY_CTRL register:
> 1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
> during high speed host mode.
> 2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
> during the reset and speed negotiation period.
> 3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
> during host suspend/resume sequence."
>
> and the same is not present on mx28 reference manual.
>
> How can we make sure we are not violating the point 2 above?
>
It is the same with i.mx28. I think Richard's patch should not
violate point 2. Richard, can you confirm it?
> Thanks,
>
> Fabio Estevam
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: mxs-phy on i.MX233 not enumerating
On Tue, Aug 14, 2012 at 10:40:21AM +0800, Chen Peter-B29397 wrote: > > > > > > According to IC guys, the logic of handling HOSTDISCONDETECT is the > > same > > > between i.mx28 and i.mx23. > > > > As pointed out by Sean, on mx23 reference manual we have the following > > text describing HOSTDISCONDETECT: > > > > "Due to a on chip issue (Errata #2791), software must > > pay attention to when to assert the HOSTDISCONDETECT bit description > > has the following: > > > > ENHOSTDISCONDETECT bit in HW_USBPHY_CTRL register: > > 1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT > > during high speed host mode. > > 2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT > > during the reset and speed negotiation period. > > 3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT > > during host suspend/resume sequence." > > > > and the same is not present on mx28 reference manual. > > > > How can we make sure we are not violating the point 2 above? > > > It is the same with i.mx28. If they're same, imx23 should be ok. The mxs_phy driver pass test on mx28. > I think Richard's patch should not > violate point 2. Richard, can you confirm it? You mean I should not set the bit in mxs_phy_on_connect? or mxs_phy_on_connect is called in wrong place? Thanks Richard > > > Thanks, > > > > Fabio Estevam > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mxs-phy on i.MX233 not enumerating
> > > > > It is the same with i.mx28. > If they're same, imx23 should be ok. The mxs_phy driver pass test > on mx28. > > I think Richard's patch should not > > violate point 2. Richard, can you confirm it? > You mean I should not set the bit in mxs_phy_on_connect? > or mxs_phy_on_connect is called in wrong place? > HW_USBPHY_CTRL.ENHOSTDISCONDETECT should be set after bus reset is finished. > Thanks > Richard > > > > > Thanks, > > > > > > Fabio Estevam > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] usb: hcd: mark controller's suspend routine as async
> > > Host controller's suspend should be executed later than root hub's, > > or the hang may occur when root hub try to visit some registers > > but host controller's suspend close the related clocks. > > Have you ever seen this happen? It should not be possible, because the > PM core is careful not to suspend a parent before its child devices. > > > Mark controller's suspend as async can make sure it is executed > > later than root hub's as host controller is the parent of root hub. > > We want to be careful about this sort of thing. Most of the async > suspend notations are for devices on a particular kind of bus, but the > notation you want to add would apply to all host controllers on any > bus. > > If you really do see a host controller suspending before its root hub, > this indicates there is a bug in the PM core. The bug should be fixed; > you shouldn't ignore it by marking all host controllers for async > suspend. > I am apologized that it does not occur after my experiments, I check this problem because one of my colleagues assumes its possibilities, and I thought dpm_wait_for_children at __device_suspend will not wait children if the dev is not async_suspend. In fact, at dpm_wait_for_children, the parent will wait if one of its child is async_suspend and this child's suspend is not finished. > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mxs-phy on i.MX233 not enumerating
On Tue, Aug 14, 2012 at 11:11:53AM +0800, Chen Peter-B29397 wrote: > > > > > > > > It is the same with i.mx28. > > If they're same, imx23 should be ok. The mxs_phy driver pass test > > on mx28. > > > I think Richard's patch should not > > > violate point 2. Richard, can you confirm it? > > You mean I should not set the bit in mxs_phy_on_connect? > > or mxs_phy_on_connect is called in wrong place? > > > > HW_USBPHY_CTRL.ENHOSTDISCONDETECT should be set after bus reset is finished. So I guess you mean "mxs_phy_on_connect is called in wrong place". Then this patch is incorrect. > > > Thanks > > Richard > > > > > > > Thanks, > > > > > > > > Fabio Estevam > > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB host isochronous transfer broken
Hi Greg, thanks for your answer. On Aug 13, 2012, at 4:42 PM, Greg KH wrote: > > After reading the code for the USB host driver for this hardware, and > reading the hardware data sheet, I'm amazed that any USB devices work on > this platform :) You really did this? I think it would take me a few days. So is the hardware data sheet public available? If yes - where do I get it? > > I think you are right in that isoc just doesn't work on the codebase you > are trying to use, but I would try asking on the raspberry-pi kernel > mailing list to see if there are any updates that you can try out for > newer versions of the kernel and drivers, I'll do that. Actually I read in a post in the raspberry pi forum that a USB guru like you is required. ;) I hope there is some progress here soon. What part of the code would you revise first? Can you give me a pointer what's the worst part of the code and where to start? > as I think a lot of work is > going on in this area last time I looked. > best of luck, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] drivers/usb/wusbcore/wa-hc.c: fix error return code
From: Julia Lawall
Convert a 0 error return code to a negative one, as returned elsewhere in the
function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x =
\(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/usb/wusbcore/wa-hc.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/wusbcore/wa-hc.c b/drivers/usb/wusbcore/wa-hc.c
index 9e4a924..a09b65e 100644
--- a/drivers/usb/wusbcore/wa-hc.c
+++ b/drivers/usb/wusbcore/wa-hc.c
@@ -46,8 +46,10 @@ int wa_create(struct wahc *wa, struct usb_interface *iface)
wa->dto_epd = &iface->cur_altsetting->endpoint[2].desc;
wa->xfer_result_size = usb_endpoint_maxp(wa->dti_epd);
wa->xfer_result = kmalloc(wa->xfer_result_size, GFP_KERNEL);
- if (wa->xfer_result == NULL)
+ if (wa->xfer_result == NULL) {
+ result = -ENOMEM;
goto error_xfer_result_alloc;
+ }
result = wa_nep_create(wa, iface);
if (result < 0) {
dev_err(dev, "WA-CDS: can't initialize notif endpoint: %d\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] drivers/usb/host/ehci-platform.c: fix error return code
From: Julia Lawall
Convert a possibly 0 error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x =
\(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/usb/host/ehci-platform.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 91acdde..764e010 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -128,8 +128,10 @@ static int __devinit ehci_platform_probe(struct
platform_device *dev)
}
hcd->regs = ioremap_nocache(hcd->rsrc_start, hcd->rsrc_len);
- if (!hcd->regs)
+ if (!hcd->regs) {
+ err = -ENOMEM;
goto err_release_region;
+ }
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err)
goto err_iounmap;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] drivers/usb/gadget/s3c-hsotg.c: fix error return code
From: Julia Lawall
Convert a 0 error return code to a negative one, as returned elsewhere in the
function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x =
\(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/usb/gadget/s3c-hsotg.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index b13e0bb..0bb617e 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -3599,6 +3599,7 @@ static int __devinit s3c_hsotg_probe(struct
platform_device *pdev)
if (hsotg->num_of_eps == 0) {
dev_err(dev, "wrong number of EPs (zero)\n");
+ ret = -EINVAL;
goto err_supplies;
}
@@ -3606,6 +3607,7 @@ static int __devinit s3c_hsotg_probe(struct
platform_device *pdev)
GFP_KERNEL);
if (!eps) {
dev_err(dev, "cannot get memory\n");
+ ret = -ENOMEM;
goto err_supplies;
}
@@ -3622,6 +3624,7 @@ static int __devinit s3c_hsotg_probe(struct
platform_device *pdev)
GFP_KERNEL);
if (!hsotg->ctrl_req) {
dev_err(dev, "failed to allocate ctrl req\n");
+ ret = -ENOMEM;
goto err_ep_mem;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] drivers/usb/host/ohci-platform.c: fix error return code
From: Julia Lawall
Convert a possibly 0 error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x =
\(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/usb/host/ohci-platform.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 10d85b9..e24ec9f 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -130,8 +130,10 @@ static int __devinit ohci_platform_probe(struct
platform_device *dev)
}
hcd->regs = ioremap_nocache(hcd->rsrc_start, hcd->rsrc_len);
- if (!hcd->regs)
+ if (!hcd->regs) {
+ err = -ENOMEM;
goto err_release_region;
+ }
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err)
goto err_iounmap;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
