Re: [V7 PATCH 02/16] usb: gadget: mv_udc: use PHY driver for udc
Hi, On Monday 18 February 2013 11:40 AM, Chao Xie wrote: Originaly, udc driver will call the callbacks in platform data for PHY initialization and shut down. With PHY driver, it will call the APIs provided by PHY driver for PHY initialization and shut down. It removes the callbacks in platform data, and at same time it removes one block in the way of enabling device tree for udc driver. Signed-off-by: Chao Xie --- drivers/usb/gadget/mv_udc.h |2 +- drivers/usb/gadget/mv_udc_core.c | 37 +++-- 2 files changed, 16 insertions(+), 23 deletions(-) diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h index 9073436..f339df4 100644 --- a/drivers/usb/gadget/mv_udc.h +++ b/drivers/usb/gadget/mv_udc.h @@ -180,7 +180,6 @@ struct mv_udc { struct mv_cap_regs __iomem *cap_regs; struct mv_op_regs __iomem *op_regs; - void __iomem*phy_regs; unsigned intmax_eps; struct mv_dqh *ep_dqh; size_t ep_dqh_size; @@ -217,6 +216,7 @@ struct mv_udc { struct work_struct vbus_work; struct workqueue_struct *qwork; + struct usb_phy *phy; struct usb_phy *transceiver; struct mv_usb_platform_data *pdata; diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c index c8cf959..d3ce1aa 100644 --- a/drivers/usb/gadget/mv_udc_core.c +++ b/drivers/usb/gadget/mv_udc_core.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include "mv_udc.h" @@ -1121,15 +1122,14 @@ static int mv_udc_enable_internal(struct mv_udc *udc) dev_dbg(&udc->dev->dev, "enable udc\n"); udc_clock_enable(udc); - if (udc->pdata->phy_init) { - retval = udc->pdata->phy_init(udc->phy_regs); - if (retval) { - dev_err(&udc->dev->dev, - "init phy error %d\n", retval); - udc_clock_disable(udc); - return retval; - } + retval = usb_phy_init(udc->phy); + if (retval) { + dev_err(&udc->dev->dev, + "init phy error %d\n", retval); + udc_clock_disable(udc); + return retval; } + udc->active = 1; return 0; @@ -1147,8 +1147,7 @@ static void mv_udc_disable_internal(struct mv_udc *udc) { if (udc->active) { dev_dbg(&udc->dev->dev, "disable udc\n"); - if (udc->pdata->phy_deinit) - udc->pdata->phy_deinit(udc->phy_regs); + usb_phy_shutdown(udc->phy); udc_clock_disable(udc); udc->active = 0; } @@ -2175,8 +2174,8 @@ static int mv_udc_probe(struct platform_device *pdev) #ifdef CONFIG_USB_OTG_UTILS if (pdata->mode == MV_USB_MODE_OTG) { - udc->transceiver = devm_usb_get_phy(&pdev->dev, - USB_PHY_TYPE_USB2); + udc->transceiver = devm_usb_get_phy_dev(&pdev->dev, + MV_USB2_OTG_PHY_INDEX); if (IS_ERR_OR_NULL(udc->transceiver)) { udc->transceiver = NULL; return -ENODEV; @@ -2194,7 +2193,7 @@ static int mv_udc_probe(struct platform_device *pdev) } } - r = platform_get_resource_byname(udc->dev, IORESOURCE_MEM, "capregs"); + r = platform_get_resource(udc->dev, IORESOURCE_MEM, 0); if (r == NULL) { dev_err(&pdev->dev, "no I/O memory resource defined\n"); return -ENODEV; @@ -2207,18 +2206,12 @@ static int mv_udc_probe(struct platform_device *pdev) return -EBUSY; } - r = platform_get_resource_byname(udc->dev, IORESOURCE_MEM, "phyregs"); - if (r == NULL) { - dev_err(&pdev->dev, "no phy I/O memory resource defined\n"); + udc->phy = devm_usb_get_phy_dev(&pdev->dev, MV_USB2_PHY_INDEX); + if (IS_ERR_OR_NULL(udc->phy)) { + udc->phy = NULL; Ideally you shouldn't do this. Consider the case where devm_usb_get_phy_dev returns -EPROBE_DEFER. In that case you should return -EPROBE_DEFER from probe instead of manually writing the return value to -ENODEV. This comment is applicable for the remaining patches that uses devm_usb_get_phy_dev. Thanks Kishon -- 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: [V2 2/8] USB: EHCI: make ehci-atmel a separate driver
On 02/15/2013 06:24 PM, Manjunath Goudar wrote: Separate the Atmel host controller driver from ehci-hcd host code into its own driver module. In V2: Resolved below compiler error. drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove': drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function 'ehci_shutdown' Signed-off-by: Manjunath Goudar Cc: Alan Stern Cc: Greg KH Cc: Grant Likely Cc: Rob Herring Cc: Andrew Victor Cc: Nicolas Ferre Cc: Jean-Christophe Plagniol-Villard Cc: linux-usb@vger.kernel.org Cc: linux-ker...@vger.kernel.org --- drivers/usb/host/Kconfig |8 + drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-atmel.c | 76 ++--- drivers/usb/host/ehci-hcd.c | 10 ++ drivers/usb/host/ehci.h |2 +- 5 files changed, 53 insertions(+), 44 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 15e8032..1ef37d7 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -170,6 +170,14 @@ config USB_EHCI_HCD_SPEAR Enables support for the on-chip EHCI controller on ST SPEAr chips. +config USB_EHCI_HCD_AT91 +tristate "Support for Atmel on-chip EHCI USB controller" +depends on USB_EHCI_HCD&& ARCH_AT91 +default y +---help--- + Enables support for the on-chip EHCI controller on + Atmel chips. + config USB_EHCI_MSM bool "Support for MSM on-chip EHCI USB controller" depends on USB_EHCI_HCD&& ARCH_MSM diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index c8fcde9..b301243 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o obj-$(CONFIG_USB_EHCI_HCD_SPEAR)+= ehci-spear.o obj-$(CONFIG_USB_OXU210HP_HCD)+= oxu210hp-hcd.o +obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o obj-$(CONFIG_USB_OHCI_HCD)+= ohci-hcd.o diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c index 27639487..3cd0dd4 100644 --- a/drivers/usb/host/ehci-atmel.c +++ b/drivers/usb/host/ehci-atmel.c @@ -15,6 +15,19 @@ #include #include #include +#include +#include +#include +#include +#include +#include + +#include "ehci.h" + +#define DRIVER_DESC "EHCI atmel driver" + +static const char hcd_name[] = "ehci-atmel"; +static struct hc_driver __read_mostly ehci_atmel_hc_driver; /* interface and function clocks */ static struct clk *iclk, *fclk; @@ -60,41 +73,6 @@ static int ehci_atmel_setup(struct usb_hcd *hcd) return ehci_setup(hcd); } -static const struct hc_driver ehci_atmel_hc_driver = { - .description= hcd_name, - .product_desc = "Atmel EHCI UHP HS", - .hcd_priv_size = sizeof(struct ehci_hcd), - - /* generic hardware linkage */ - .irq= ehci_irq, - .flags = HCD_MEMORY | HCD_USB2, - - /* basic lifecycle operations */ - .reset = ehci_atmel_setup, - .start = ehci_run, - .stop = ehci_stop, - .shutdown = ehci_shutdown, - - /* managing i/o requests and associated device resources */ - .urb_enqueue= ehci_urb_enqueue, - .urb_dequeue= ehci_urb_dequeue, - .endpoint_disable = ehci_endpoint_disable, - .endpoint_reset = ehci_endpoint_reset, - - /* scheduling support */ - .get_frame_number = ehci_get_frame, - - /* root hub support */ - .hub_status_data= ehci_hub_status_data, - .hub_control= ehci_hub_control, - .bus_suspend= ehci_bus_suspend, - .bus_resume = ehci_bus_resume, - .relinquish_port= ehci_relinquish_port, - .port_handed_over = ehci_port_handed_over, - - .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete, -}; - static u64 at91_ehci_dma_mask = DMA_BIT_MASK(32); static int ehci_atmel_drv_probe(struct platform_device *pdev) @@ -210,7 +188,33 @@ static struct platform_driver ehci_atmel_driver = { .remove = ehci_atmel_drv_remove, .shutdown = usb_hcd_platform_shutdown, .driver = { - .name = "atmel-ehci", + .name = hcd_name, This change will cause atmel ehci won't work with the none device tree kernel. it can be fixed with replace other places using "atmel-ehci" with , that means replace "atmel-ehci" with "ehci-atmel" at other places. Best Regards, Bo Shen -- 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.
[PATCH] pci: do not try to assign irq 255
The PCI config space reseves a byte for the interrupt line, so irq 255 actually refers to 'not set'. However, the 'irq' field for struct pci_dev is an integer, so the original meaning is lost, causing the system to assign an interrupt '255', which fails. So we should _not_ assign an interrupt value here, and allow upper layers to fixup things. This patch make PCI devices with MSI interrupts only (like the xhci device on certain HP laptops) work properly. Cc: Frederik Himpe Cc: Oliver Neukum Cc: David Haerdeman Cc: linux-usb@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Hannes Reinecke diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 6186f03..a2db887f 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -923,7 +923,8 @@ static void pci_read_irq(struct pci_dev *dev) dev->pin = irq; if (irq) pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq); - dev->irq = irq; + if (irq < 255) + dev->irq = irq; } void set_pcie_port_type(struct pci_dev *pdev) -- 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: [V2 2/8] USB: EHCI: make ehci-atmel a separate driver
On Monday 18 February 2013, Bo Shen wrote: > > - .name = "atmel-ehci", > > + .name = hcd_name, > > This change will cause atmel ehci won't work with the none device tree > kernel. > > it can be fixed with replace other places using "atmel-ehci" with > , that means replace "atmel-ehci" with "ehci-atmel" at other > places. Ah, that is right. Thanks for pointing it out! Manjunath, please revert this change and ensure you are not changing the contents of the 'platform_driver->name' field in any of the drivers. Arnd -- 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: Fwd: PROBLEM: Permanent kernel panic in USB hub driver - 3.5.0-22
Hi, >> However, I think the root cause is the same as >> in previous cores, so it is still would be worth to analyze them. >> Here is a new picture of the panic: >> https://dl.dropbox.com/u/8276110/3.7.4%20panic.jpg > > Do you have the UAS driver compiled in? I see some functions that could > only be called after the UAS driver allocates a streams context (i.e. > xhci_stream_id_to_ring). It doesn't seem to be related to the Set > Address timeout crash that was your previous issue. The crash could be a uas driver bug, please pick up fixes from http://www.kraxel.org/cgit/linux/log/?h=uas (greg's usb-next tree will do too). That will not make the uas driver work due to the radix tree bug, but the uas driver's error handling should be solid enougth that xhci driver bugs don't make uas crash the box. cheers, Gerd -- 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
[RFC PATCH] usb/core: add current frame_number sysfs attr to hcd
This allows user space to retrieve the current frame number on a USB as returned by usb_get_current_frame_number(...) via sysfs. Signed-off-by: Stefan Tauner --- That's sadly not necessarily the raw value seen on the bus because the individual driver functions called by usb_get_current_frame_number(...) seem to limit the possible range to the "schedule horizon" of isochronous packets. IMHO the function name is a misnomer and I would like to hear your opinion on this, a possible new name for it and a better way to retrieve the real/raw value. The rationale for this patch can be found in the thread with the subject "Correlating SOF with host system time" from last december (201212042020.qb4kkt0n008...@mail2.student.tuwien.ac.at). My whole use case/idea was kinda frowned upon then, but there was little discussion about how it should/could be implemented in the kernel code in case one really wants to try it. Adding the sysfs attribute was the easiest way for me to communicate this to user space, but at least for my use case a non-polling approach would have been better. Any suggestions on how this could be done by a newbie like me are very welcome. The patch is against version 3.8.0-6.13 of the Ubuntu 13.04 development kernel, but I really hope it is simple enough to apply upstream, but I don't expect it to get merged as is anyway, so please don't flame too much if it does not cleanly. :) I have tested it on my Ubuntu 12.04 system, lspci -nn | grep USB 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 06) 00:1d.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] (rev 06) It creates two files: /sys/devices/pci\:00/\:00\:1a.0/usb1/frame_number and /sys/devices/pci\:00/\:00\:1d.0/usb2/frame_number which contain sane, distinct, looping values between 0 and about 2^10 - 1 --- drivers/usb/core/hcd.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 8e64adf..9c8e9ab 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -862,10 +862,26 @@ static DEVICE_ATTR(authorized_default, 0644, usb_host_authorized_default_show, usb_host_authorized_default_store); +/* + * Show the current frame number as returned by usb_get_current_frame_number() + * (or a negative value in the case of errors) + */ +static ssize_t usb_bus_frame_number_show(struct device *dev, +struct device_attribute *attr, +char *buf) +{ + struct usb_device *rh_usb_dev = to_usb_device(dev); + int fn = usb_get_current_frame_number(rh_usb_dev); + return snprintf(buf, PAGE_SIZE, "%d\n", fn); +} + +static DEVICE_ATTR(frame_number, S_IRUGO, usb_bus_frame_number_show, NULL); + /* Group all the USB bus attributes */ static struct attribute *usb_bus_attrs[] = { &dev_attr_authorized_default.attr, + &dev_attr_frame_number.attr, NULL, }; -- Kind regards, Stefan Tauner -- 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: [RFC PATCH] usb/core: add current frame_number sysfs attr to hcd
On Mon, Feb 18, 2013 at 03:34:07PM +0100, Stefan Tauner wrote: > This allows user space to retrieve the current frame number on a USB > as returned by usb_get_current_frame_number(...) via sysfs. > > Signed-off-by: Stefan Tauner > --- > That's sadly not necessarily the raw value seen on the bus because > the individual driver functions called by usb_get_current_frame_number(...) > seem to limit the possible range to the "schedule horizon" of isochronous > packets. IMHO the function name is a misnomer and I would like to hear your > opinion on this, a possible new name for it and a better way to retrieve the > real/raw value. > > The rationale for this patch can be found in the thread with the subject > "Correlating SOF with host system time" from last december > (201212042020.qb4kkt0n008...@mail2.student.tuwien.ac.at). > My whole use case/idea was kinda frowned upon then, but there was little > discussion about how it should/could be implemented in the kernel code in > case one really wants to try it. For those of us with bad memories, care to expand on why you want this in the changelog body of the patch so that the world will remember it as well? > Adding the sysfs attribute was the easiest way for me to communicate > this to user space, but at least for my use case a non-polling approach > would have been better. Any suggestions on how this could be done by a > newbie like me are very welcome. Whenever you add/modify/remove a sysfs attribute, you also need to document it in Documentation/ABI/. Care to do that and resend this patch? thanks, 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
[PATCH v3] xhci - correct comp_mode_recovery_timer on return from hibernate
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware) was a workaround for systems using the SN65LVPE502CP controller, but it introduced a bug where resume from hibernate would add the comp_mode_recovery_timer to the timer queue while it was already active when saved to disk on hibernate. This caused list_add corruption leading to a crash when resuming from hibernate. The original patch erroneously assumed that the timer would be deleted by a call to xhci_suspend() or xhci_stop(), but neither of these calls is made during the hibernate sequence. When returning from hibernate, the timer was still active, and the attempt to list_add the same timer corrupted the list. We can avoid this problem when resuming from hibernate by first deleting the timer and then initializing it and adding it to the timer list. Removed extraneous parenthesis from conditional statements of the original commit. Signed-off-by: Tony Camuso Acked-by: Don Zickus --- drivers/usb/host/xhci.c | 13 ++--- 1 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index f1f01a8..267a7b1 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -732,7 +732,7 @@ void xhci_stop(struct usb_hcd *hcd) /* Deleting Compliance Mode Recovery Timer */ if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && - (!(xhci_all_ports_seen_u0(xhci + !(xhci_all_ports_seen_u0(xhci))) del_timer_sync(&xhci->comp_mode_recovery_timer); if (xhci->quirks & XHCI_AMD_PLL_FIX) @@ -927,7 +927,7 @@ int xhci_suspend(struct xhci_hcd *xhci) * is about to be suspended. */ if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && - (!(xhci_all_ports_seen_u0(xhci { + !(xhci_all_ports_seen_u0(xhci))) { del_timer_sync(&xhci->comp_mode_recovery_timer); xhci_dbg(xhci, "Compliance Mode Recovery Timer Deleted!\n"); } @@ -988,6 +988,13 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated) /* If restore operation fails, re-initialize the HC during resume */ if ((temp & STS_SRE) || hibernated) { + + if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && + !(xhci_all_ports_seen_u0(xhci))) { + del_timer_sync(&xhci->comp_mode_recovery_timer); + xhci_dbg(xhci, "Compliance Mode Recovery Timer deleted!\n"); + } + /* Let the USB core know _both_ roothubs lost power. */ usb_root_hub_lost_power(xhci->main_hcd->self.root_hub); usb_root_hub_lost_power(xhci->shared_hcd->self.root_hub); @@ -1071,7 +1078,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated) * to suffer the Compliance Mode issue again. It doesn't matter if * ports have entered previously to U0 before system's suspension. */ - if (xhci->quirks & XHCI_COMP_MODE_QUIRK) + if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && !hibernated) compliance_mode_recovery_timer_init(xhci); /* Re-enable port polling. */ -- 1.7.1 -- 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: [regression][v3.8rc5->v3.8rc6] ehci-pci fails with error -110 on read/[64,all]
CC'ing the author of the patch. 2013/2/18 Ronald : This e-mail is a follow-up as requested in this bug[1]. I will repost everything so far in this e-mail. Please CC me as I'm not subscribed to your list. Current head gives this when I plug a 'Mass Storage Device' into a 2.0 hub: [ 842.760400] hub 1-0:1.0: unable to enumerate USB device on port 3 [ 843.080058] usb 1-3: new high-speed USB device number 48 using ehci-pci [ 858.230072] usb 1-3: device descriptor read/64, error -110 [ 873.490070] usb 1-3: device descriptor read/64, error -110 Reverting the following commit makes it work again: commit 55bcdce8a8228223ec4d17d8ded8134ed265d2c5 Author: Alan Stern Date: Fri Jan 25 16:52:45 2013 -0500 USB: EHCI: remove ASS/PSS polling timeout This patch (as1647) attempts to work around a problem that seems to affect some nVidia EHCI controllers. They sometimes take a very long time to turn off their async or periodic schedules. I don't know if this is a result of other problems, but in any case it seems wise not to depend on schedule enables or disables taking effect in any specific length of time. The patch removes the existing 20-ms timeout for enabling and disabling the schedules. The driver will now continue to poll the schedule state at 1-ms intervals until the controller finally decides to obey the most recent command issued by the driver. Just in case this hides a problem, a debugging message will be logged if the controller takes longer than 20 polls. I don't know if this will actually fix anything, but it can't hurt. Signed-off-by: Alan Stern Tested-by: Piergiorgio Sartor CC: Signed-off-by: Greg Kroah-Hartman diff --git a/drivers/usb/host/ehci-timer.c b/drivers/usb/host/ehci-timer.c index 20dbdcb..f904071 100644 --- a/drivers/usb/host/ehci-timer.c +++ b/drivers/usb/host/ehci-timer.c @@ -113,14 +113,15 @@ static void ehci_poll_ASS(struct ehci_hcd *ehci) if (want != actual) { - /* Poll again later, but give up after about 20 ms */ - if (ehci->ASS_poll_count++ < 20) { - ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true); - return; - } - ehci_dbg(ehci, "Waited too long for the async schedule status(%x/%x), giving up\n", - want, actual); + /* Poll again later */ + ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true); + ++ehci->ASS_poll_count; + return; } + + if (ehci->PSS_poll_count > 20) + ehci_dbg(ehci, "PSS poll count reached %d\n", + ehci->PSS_poll_count); ehci->PSS_poll_count = 0; /* The status is up-to-date; restart or stop the schedule as needed */ Please note, that I'm using the 'irqpoll' cmdline to improve system stability. What I forgot to mention in the bug was the chipset: 00:10.3 USB controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd. KT4AV motherboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- >>> Latency: 32, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 21 Region 0: Memory at dffeff00 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ehci-pci Yes, it's 10 years old, and no I'm not scrooge. We are waiting a while for computer prices to plummet mkay? [1]: https://bugzilla.kernel.org/show_bug.cgi?id=54031 >>> >>> Would like to add that while searching the mailing lists I stumbled on this: >>> >>> http://marc.info/?l=linux-usb&m=136045531311402&w=4 >>> >>> It's an entirely seperate USB issue in this cycle. The person is doing >>> git bisect to find the regression. I did another approach as >>> recompiling the full kernel on a 1,25GHz isn't even remotely funny >>> anymore. >>> >>> On top of HEAD I started reverting groups of USB EHCI patches one by >>> one. I'm just mentioning it since I'm not sure if this procedure is >>> accepted here. >> >> Did some more testing this morning. It seems like it's a race >> con
Re: [PATCH v3] xhci - correct comp_mode_recovery_timer on return from hibernate
The difference between v2 and v3 of this patch was mostly cosmetic. (!(xhci_all_ports_seen_u0(xhci)) ... was changed to... !(xhci_all_ports_seen_u0(xhci)) And ... "Compliance Mode Recovery Timer Deleted!\n" ... was changed to ... "Compliance Mode Recovery Timer deleted!\n" On 02/18/2013 12:52 PM, Tony Camuso wrote: Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware) was a workaround for systems using the SN65LVPE502CP controller, but it introduced a bug where resume from hibernate would add the comp_mode_recovery_timer to the timer queue while it was already active when saved to disk on hibernate. This caused list_add corruption leading to a crash when resuming from hibernate. The original patch erroneously assumed that the timer would be deleted by a call to xhci_suspend() or xhci_stop(), but neither of these calls is made during the hibernate sequence. When returning from hibernate, the timer was still active, and the attempt to list_add the same timer corrupted the list. We can avoid this problem when resuming from hibernate by first deleting the timer and then initializing it and adding it to the timer list. Removed extraneous parenthesis from conditional statements of the original commit. Signed-off-by: Tony Camuso Acked-by: Don Zickus --- drivers/usb/host/xhci.c | 13 ++--- 1 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index f1f01a8..267a7b1 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -732,7 +732,7 @@ void xhci_stop(struct usb_hcd *hcd) /* Deleting Compliance Mode Recovery Timer */ if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && - (!(xhci_all_ports_seen_u0(xhci + !(xhci_all_ports_seen_u0(xhci))) del_timer_sync(&xhci->comp_mode_recovery_timer); if (xhci->quirks & XHCI_AMD_PLL_FIX) @@ -927,7 +927,7 @@ int xhci_suspend(struct xhci_hcd *xhci) * is about to be suspended. */ if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && - (!(xhci_all_ports_seen_u0(xhci { + !(xhci_all_ports_seen_u0(xhci))) { del_timer_sync(&xhci->comp_mode_recovery_timer); xhci_dbg(xhci, "Compliance Mode Recovery Timer Deleted!\n"); } @@ -988,6 +988,13 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated) /* If restore operation fails, re-initialize the HC during resume */ if ((temp & STS_SRE) || hibernated) { + + if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && + !(xhci_all_ports_seen_u0(xhci))) { + del_timer_sync(&xhci->comp_mode_recovery_timer); + xhci_dbg(xhci, "Compliance Mode Recovery Timer deleted!\n"); + } + /* Let the USB core know _both_ roothubs lost power. */ usb_root_hub_lost_power(xhci->main_hcd->self.root_hub); usb_root_hub_lost_power(xhci->shared_hcd->self.root_hub); @@ -1071,7 +1078,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated) * to suffer the Compliance Mode issue again. It doesn't matter if * ports have entered previously to U0 before system's suspension. */ - if (xhci->quirks & XHCI_COMP_MODE_QUIRK) + if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && !hibernated) compliance_mode_recovery_timer_init(xhci); /* Re-enable port polling. */ -- 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/3] Input: add new keycodes for passenger control units
Entertainment systems used in aircraft need additional keycodes for their Passenger Control Units, so let's add them. Signed-off-by: Dmitry Torokhov --- include/uapi/linux/input.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 54a3b49..e6d9609 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -702,6 +702,11 @@ struct input_keymap_entry { #define KEY_CAMERA_LEFT0x219 #define KEY_CAMERA_RIGHT 0x21a +#define KEY_ATTENDANT_ON 0x21b +#define KEY_ATTENDANT_OFF 0x21c +#define KEY_ATTENDANT_TOGGLE 0x21d /* Attendant call on or off */ +#define KEY_LIGHTS_TOGGLE 0x21e /* Reading light on or off */ + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 -- 1.7.11.7 -- 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 0/3] Introduce driver for IMS PCU devices
IMS, an In Flight Entertainment System provider, has a number of seat displays Linux. To interact with the user IMS uses a passenger Control Unit (PCU), which communicates with Rave Display Unit via a USB interface. Originally large part of the PCU handling was done from userspace and so it presents itself as two distinct USB devices: one is a standard HID mouse and another is a CDC-ACM modem-like device. The latter one was used by IMS userspace software to get the status of all PCU buttons and perform other operations. However the fact that with the custom userspace handling the device resides outside of the standard input framework hinders use of the device elsewhere in the stack and this patch series attempts to fix this issue by creating a proper input driver for the device. If the device was purely input device it would also be possible to use cdc-acm + userspace solution and loop the input events back into the kernel via uinput, however the device also allows control its key backlight, which exported as a standard LED device, and this functionality is not available through uinput (nor should it be). Firmware update is also implemented via the standard "request_firmware" mechanism. The patch series consists of 3 parts: - a patch adding new keycodes needed for PCU; - the driver itself; - a patch to cdc-acm driver to ignore PCU devices when ims-pcu driver is enabled. Thanks. -- Dmitry -- 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 2/3] Input: add IMS Passenger Control Unit driver
The PCU is a device installed in the armrest of a plane seat and is connected to IMS Rave Entertainment System. It has a set of control buttons (Volume Up/Down, Attendant, Lights, etc) on one side and gamepad-like controls on the other side. Originally the device was handled from userspace and because of that it presents itself on USB bus as a CDC-ACM modem device that however can not make calls. However the custom handling is not as convenient as using standard input subsystem facilities. If it was pure input device it would be possible to continue using userspace solution (moving it over to uinput), but the device also has backlighted keys which can not be supported via uinput. Signed-off-by: Dmitry Torokhov --- drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile |1 + drivers/input/misc/ims-pcu.c | 1907 ++ 3 files changed, 1918 insertions(+) create mode 100644 drivers/input/misc/ims-pcu.c diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 798ba29..9d32716 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -606,6 +606,16 @@ config INPUT_ADXL34X_SPI To compile this driver as a module, choose M here: the module will be called adxl34x-spi. +config INPUT_IMS_PCU + tristate "IMS Passenger Control Unit driver" + depends on USB + depends on LEDS_CLASS + help + Say Y here if you have system with IMS Rave Passenger Control Unit. + + To compile this driver as a module, choose M here: the module will be + called ims_pcu. + config INPUT_CMA3000 tristate "VTI CMA3000 Tri-axis accelerometer" help diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index ae5d9fd..33085784 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o obj-$(CONFIG_INPUT_GPIO_BEEPER)+= gpio-beeper.o obj-$(CONFIG_INPUT_GPIO_TILT_POLLED) += gpio_tilt_polled.o obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o +obj-$(CONFIG_INPUT_IMS_PCU)+= ims-pcu.o obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c new file mode 100644 index 000..10bd73c --- /dev/null +++ b/drivers/input/misc/ims-pcu.c @@ -0,0 +1,1907 @@ +/* + * Driver for IMS Passenger Control Unit Devices + * + * Copyright (C) 2013 The IMS Company + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define IMS_PCU_KEYMAP_LEN 32 + +struct ims_pcu_buttons { + struct input_dev *input; + char name[32]; + char phys[32]; + unsigned short keymap[IMS_PCU_KEYMAP_LEN]; +}; + +struct ims_pcu_gamepad { + struct input_dev *input; + char name[32]; + char phys[32]; +}; + +struct ims_pcu_backlight { + struct led_classdev cdev; + struct work_struct work; + enum led_brightness desired_brightness; + char name[32]; +}; + +#define IMS_PCU_PART_NUMBER_LEN15 +#define IMS_PCU_SERIAL_NUMBER_LEN 8 +#define IMS_PCU_DOM_LEN8 +#define IMS_PCU_FW_VERSION_LEN (9 + 1) +#define IMS_PCU_BL_VERSION_LEN (9 + 1) +#define IMS_PCU_BL_RESET_REASON_LEN(2 + 1) + +#define IMS_PCU_BUF_SIZE 128 + +struct ims_pcu { + struct usb_device *udev; + struct device *dev; /* control interface's device, used for logging */ + + unsigned int device_no; + + bool bootloader_mode; + + char part_number[IMS_PCU_PART_NUMBER_LEN]; + char serial_number[IMS_PCU_SERIAL_NUMBER_LEN]; + char date_of_manufacturing[IMS_PCU_DOM_LEN]; + char fw_version[IMS_PCU_FW_VERSION_LEN]; + char bl_version[IMS_PCU_BL_VERSION_LEN]; + char reset_reason[IMS_PCU_BL_RESET_REASON_LEN]; + int update_firmware_status; + + struct usb_interface *ctrl_intf; + + struct usb_endpoint_descriptor *ep_ctrl; + struct urb *urb_ctrl; + u8 *urb_ctrl_buf; + dma_addr_t ctrl_dma; + size_t max_ctrl_size; + + struct usb_interface *data_intf; + + struct usb_endpoint_descriptor *ep_in; + struct urb *urb_in; + u8 *urb_in_buf; + dma_addr_t read_dma; + size_t max_in_size; + + struct usb_endpoint_descriptor *ep_out; + u8 *urb_out_buf; + size_t max_out_size; + + u8 read_buf[IMS_PCU_BUF_SIZE]; + u8 read_pos; + u8 check_sum; + bool have_stx; + bool ha
[PATCH 3/3] USB: cdc-acm - blacklist IMS PCU device
The IMS PCU (Passenger Control Unit) device used custom protocol over serial line, so it is presenting itself as CDC ACM device. Now that we have proper in-kernel driver for it we need to black-list the device in cdc-acm driver. Signed-off-by: Dmitry Torokhov --- drivers/usb/class/cdc-acm.c | 13 + drivers/usb/class/cdc-acm.h | 1 + 2 files changed, 14 insertions(+) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index 2d92cce..3c8473d 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -987,6 +987,10 @@ static int acm_probe(struct usb_interface *intf, /* normal quirks */ quirks = (unsigned long)id->driver_info; + + if (quirks == IGNORE_DEVICE) + return -ENODEV; + num_rx_buf = (quirks == SINGLE_RX_URB) ? 1 : ACM_NR; /* handle quirks deadly to normal probing*/ @@ -1691,6 +1695,15 @@ static const struct usb_device_id acm_ids[] = { .driver_info = NO_DATA_INTERFACE, }, +#if IS_ENABLED(CONFIG_INPUT_IMS_PCU) + { USB_DEVICE(0x04d8, 0x0082), /* Application mode */ + .driver_info = IGNORE_DEVICE, + }, + { USB_DEVICE(0x04d8, 0x0083), /* Bootloader mode */ + .driver_info = IGNORE_DEVICE, + }, +#endif + /* control interfaces without any protocol set */ { USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM, USB_CDC_PROTO_NONE) }, diff --git a/drivers/usb/class/cdc-acm.h b/drivers/usb/class/cdc-acm.h index 35ef887..0f76e4a 100644 --- a/drivers/usb/class/cdc-acm.h +++ b/drivers/usb/class/cdc-acm.h @@ -128,3 +128,4 @@ struct acm { #define NO_CAP_LINE4 #define NOT_A_MODEM8 #define NO_DATA_INTERFACE 16 +#define IGNORE_DEVICE 32 -- 1.7.11.7 -- 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 3/3] USB: cdc-acm - blacklist IMS PCU device
On Mon, Feb 18, 2013 at 11:05:57AM -0800, Dmitry Torokhov wrote: > The IMS PCU (Passenger Control Unit) device used custom protocol over serial > line, so it is presenting itself as CDC ACM device. > > Now that we have proper in-kernel driver for it we need to black-list the > device in cdc-acm driver. > > Signed-off-by: Dmitry Torokhov Acked-by: Greg Kroah-Hartman -- 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: [RFC PATCH] usb/core: add current frame_number sysfs attr to hcd
On Mon, 18 Feb 2013, Stefan Tauner wrote: > This allows user space to retrieve the current frame number on a USB > as returned by usb_get_current_frame_number(...) via sysfs. > > Signed-off-by: Stefan Tauner > --- > That's sadly not necessarily the raw value seen on the bus because > the individual driver functions called by usb_get_current_frame_number(...) > seem to limit the possible range to the "schedule horizon" of isochronous > packets. IMHO the function name is a misnomer and I would like to hear your > opinion on this, a possible new name for it and a better way to retrieve the > real/raw value. A problem, as you point out, is that the individual host controller drivers are somewhat careless about how they implement this. For example, the value reported by ehci-hcd increments 125 us before the value seen on the bus (in addition to being limited to the "schedule horizon" for no good reason). 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: Linux 3.8 broken for MacBookAir5,1
On Sun, 10 Feb 2013, Otavio Salvador wrote: > On Sun, Feb 10, 2013 at 12:47 PM, Alan Stern > wrote: > > On Sun, 10 Feb 2013, Otavio Salvador wrote: > >> I do have EHCI and PCI enabled so it should be working. Any clue about > >> why it breaks it? > > > > Perhaps your system is not loading the new ehci-pci kernel module. > > Yes; it should be the cause as building it built-in makes it work. > However it is a regression from my point of view. > > Those are the controllers I have in my system: > > 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series > Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) > 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series > Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) > 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series > Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) > > I thought the ehci-pci module would be load for every ehci PCI; What > do you think? The kernel can't guarantee anything about what driver modules are loaded. That's up to userspace. In particular, the initramfs image must be set up properly (if that is where these modules are loaded from). 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: Linux 3.8 broken for MacBookAir5,1
On Mon, Feb 18, 2013 at 7:09 PM, Alan Stern wrote: > On Sun, 10 Feb 2013, Otavio Salvador wrote: > >> On Sun, Feb 10, 2013 at 12:47 PM, Alan Stern >> wrote: >> > On Sun, 10 Feb 2013, Otavio Salvador wrote: >> >> I do have EHCI and PCI enabled so it should be working. Any clue about >> >> why it breaks it? >> > >> > Perhaps your system is not loading the new ehci-pci kernel module. >> >> Yes; it should be the cause as building it built-in makes it work. >> However it is a regression from my point of view. >> >> Those are the controllers I have in my system: >> >> 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series >> Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) >> 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series >> Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) >> 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series >> Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) >> >> I thought the ehci-pci module would be load for every ehci PCI; What >> do you think? > > The kernel can't guarantee anything about what driver modules are > loaded. That's up to userspace. In particular, the initramfs image > must be set up properly (if that is where these modules are loaded > from). But why kernel cannot load it if we have a PCI subsystem? Or do you think my initrd did not put the module on the initramfs image? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- 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: ->drop_endpoint being called for disabled endpoints
On Fri, 15 Feb 2013, Felipe Balbi wrote: > Hi all, > > I keep seeing the following messages when transferring data to any USB3 > mass storage I have (tried 3 different ones already): > > [618002.014556] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with > disabled ep 88012976cd40 > [618002.014562] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with > disabled ep 88012976cd80 > > It looks like usbcore is calling ->drop_endpoint() for endpoints which > are already disabled. I wonder if that's something legal to do or if we > want to protect calls to ->drop_endpoint() with if (ep->enabled) check. There was a thread on this topic a couple of weeks ago: http://marc.info/?t=13587409252&r=1&w=2 Device resets cause the hardware to disable the endpoint rings, but apparently xhci-hcd doesn't take this into account. Hence it ends up trying to drop endpoints which are already disabled, causing those error messages. > I'll add a WARN_ONCE() later just to check who's to blame here, but it's > a pretty annoying message to see all the time. :-) > > How about something like below ? No, I think this needs to be fixed in xhci-hcd. 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: [PATCH 2/2] USB: EHCI: make ehci-orion a separate driver
On Fri, 15 Feb 2013, Arnd Bergmann wrote: > From: Manjunath Goudar > > With the multiplatform changes in arm-soc tree, it becomes > possible to enable the mvebu platform (which uses > ehci-orion) at the same time as other platforms that require > a conflicting EHCI bus glue. At the moment, this results > in a warning like > > drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined > [enabled by default] > drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the > previous definition > drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined > but not used [-Wunused-variable] > > and an ehci driver that only works on one of them. > > With the infrastructure added by Alan Stern in patch 3e0232039 > "USB: EHCI: prepare to make ehci-hcd a library module", we can > avoid this problem by turning a bus glue into a separate > module, as we do here for the orion bus glue. > --- a/drivers/usb/host/Makefile > +++ b/drivers/usb/host/Makefile > @@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o > > obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o > obj-$(CONFIG_USB_EHCI_HCD_VT8500)+= ehci-vt8500.o > +obj-$(CONFIG_USB_EHCI_HCD_ORION)+= ehci-orion.o Both of these two new lines should be formatted like the other lines in this file (i.e., with tabs at the corresponding places), and they should come before the OXU210HP_HCD entry so that they are next to the other EHCI-related lines. > --- a/drivers/usb/host/ehci-orion.c > +++ b/drivers/usb/host/ehci-orion.c > @@ -17,6 +17,13 @@ > #include > #include > #include > +#include > +#include > +#include > +#include Is this line really needed? > @@ -34,6 +41,17 @@ > #define USB_PHY_IVREF_CTRL 0x440 > #define USB_PHY_TST_GRP_CTRL 0x450 > > +#define DRIVER_DESC "EHCI orion driver" > + > +static const char hcd_name[] = "ehci-orion"; > + > +static struct hc_driver __read_mostly ehci_orion_hc_driver; > + > +static const struct ehci_driver_overrides orion_overrides __initdata = { > + .reset = ehci_setup, > +}; This is not necessary; ehci_setup is the default value anyway. This structure can be omitted. > @@ -323,8 +296,6 @@ static int __exit ehci_orion_drv_remove(struct > platform_device *pdev) > return 0; > } > > -MODULE_ALIAS("platform:orion-ehci"); > - > static const struct of_device_id ehci_orion_dt_ids[] = { > { .compatible = "marvell,orion-ehci", }, > {}, > @@ -336,8 +307,31 @@ static struct platform_driver ehci_orion_driver = { > .remove = __exit_p(ehci_orion_drv_remove), > .shutdown = usb_hcd_platform_shutdown, > .driver = { > - .name = "orion-ehci", > + .name = hcd_name, Is this really what you want -- changing the driver name from "orion-ehci" to "ehci-orion"? Is that liable to cause trouble? > +MODULE_DESCRIPTION(DRIVER_DESC); > +MODULE_ALIAS("platform:ehci-orion"); And is this really what you want -- changing the alias from "platform:orion-ehci" to "platform:ehci-orion"? 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: Linux 3.8 broken for MacBookAir5,1
On Mon, 18 Feb 2013, Otavio Salvador wrote: > >> I thought the ehci-pci module would be load for every ehci PCI; What > >> do you think? > > > > The kernel can't guarantee anything about what driver modules are > > loaded. That's up to userspace. In particular, the initramfs image > > must be set up properly (if that is where these modules are loaded > > from). > > But why kernel cannot load it if we have a PCI subsystem? Or do you > think my initrd did not put the module on the initramfs image? That's exactly what I think. See this message and the corresponding thread: http://marc.info/?l=linux-usb&m=136074995914335&w=2 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: Linux 3.8 broken for MacBookAir5,1
On Mon, Feb 18, 2013 at 7:38 PM, Alan Stern wrote: > On Mon, 18 Feb 2013, Otavio Salvador wrote: > >> >> I thought the ehci-pci module would be load for every ehci PCI; What >> >> do you think? >> > >> > The kernel can't guarantee anything about what driver modules are >> > loaded. That's up to userspace. In particular, the initramfs image >> > must be set up properly (if that is where these modules are loaded >> > from). >> >> But why kernel cannot load it if we have a PCI subsystem? Or do you >> think my initrd did not put the module on the initramfs image? > > That's exactly what I think. See this message and the corresponding > thread: > > http://marc.info/?l=linux-usb&m=136074995914335&w=2 Thanks Alan, this was the problem. Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- 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: [RFC PATCH] usb/core: add current frame_number sysfs attr to hcd
On Mon, 18 Feb 2013 07:20:56 -0800 Greg KH wrote: > On Mon, Feb 18, 2013 at 03:34:07PM +0100, Stefan Tauner wrote: > > This allows user space to retrieve the current frame number on a USB > > as returned by usb_get_current_frame_number(...) via sysfs. > > > > Signed-off-by: Stefan Tauner > > --- > > That's sadly not necessarily the raw value seen on the bus because > > the individual driver functions called by usb_get_current_frame_number(...) > > seem to limit the possible range to the "schedule horizon" of isochronous > > packets. IMHO the function name is a misnomer and I would like to hear your > > opinion on this, a possible new name for it and a better way to retrieve the > > real/raw value. > > > > The rationale for this patch can be found in the thread with the subject > > "Correlating SOF with host system time" from last december > > (201212042020.qb4kkt0n008...@mail2.student.tuwien.ac.at). > > My whole use case/idea was kinda frowned upon then, but there was little > > discussion about how it should/could be implemented in the kernel code in > > case one really wants to try it. > > For those of us with bad memories, care to expand on why you want this > in the changelog body of the patch so that the world will remember it as > well? Well, I am not entirely sure if even I want this in (as is) yet, because it is just a part of a complete solution for my problem and I can't imagine a reason why user space would want to know this odd value as is. So I can not give a committable rationale yet, but I can sum up what I am trying to do eventually: I try to map SOF counters to CLOCK_REALTIME timestamps in user space. Later I want to use that to establish a global time base on microcontrollers connected via USB without the hassle of running NTP or PTP over USB. In user space I am waiting for changes in the frame_counter sysfs file by reading it and comparing its contents to values previously read in a busy loop, which is of course not very elegant but it works - apart from the fact that the returned values are not the raw values (and as Alan noted, might also be off a bit)... :) Therefore I am currently playing around with a usb_hcd_get_real_frame_number() which uses a ehci_get_real_frame() function hacked into ehci-hcd.c which returns the actual SOF counter without the artificial horizon limit, but this is of course not committable. I wonder though why the limitation is there in the first place. Most users of usb_get_current_frame_number() seem rather unhappy with the limitation (e.g. drivers/media/usb/uvc/uvc_video.c) or don't care because they cap the returned value to the (locally defined(!)) minimum of the schedule horizon (0xFF everywhere AFAICS). Only very few use it directly to determine a possible scheduling (e.g. drivers/isdn/hisax/st5481_d.c which looks rather dubious to my naive eyes BTW). So from the user's perspective I don't see a reason why the artificially limited reply should be returned instead of the complete value. I have not checked if the raw value is available on all HCDs, but I assume it is. Wouldn't it make sense to change usb_hcd_get_frame_number() to return the raw value and add another one that returns the actual limit of the schedule horizon e.g. periodic_size in the case of EHCI(?) for those users that want to scheduler packets? If not, I would really like to see the documentation of usb_get_current_frame_number() be changed to make it more clear that it is not the raw SOF value and *why*. I have not figured out what *exactly* it is yet/how the iso scheduling works... grasping the kernel - even a subsystem - is quite an effort :) If/when I do I will send a documentation patch. If you think refactoring get_frame_number should be done I would be glad to work on it. A few pointers to what the result should look like and any obvious pitfalls would be appreciated in that case. > Whenever you add/modify/remove a sysfs attribute, you also need to > document it in Documentation/ABI/. Care to do that and resend this > patch? Sure, if you think it makes sense to add the code as is, I can do that any time. Thanks for the amazingly fast reply BTW. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- 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] pci: do not try to assign irq 255
On Mon, Feb 18, 2013 at 11:09:53AM +0100, Hannes Reinecke wrote: >The PCI config space reseves a byte for the interrupt line, >so irq 255 actually refers to 'not set'. >However, the 'irq' field for struct pci_dev is an integer, >so the original meaning is lost, causing the system to >assign an interrupt '255', which fails. > >So we should _not_ assign an interrupt value here, and >allow upper layers to fixup things. > >This patch make PCI devices with MSI interrupts only >(like the xhci device on certain HP laptops) work properly. Just tested and it works for me. Thank you. Tested-by: David Härdeman >Cc: Frederik Himpe >Cc: Oliver Neukum >Cc: David Haerdeman >Cc: linux-usb@vger.kernel.org >Cc: linux-...@vger.kernel.org >Signed-off-by: Hannes Reinecke > >diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c >index 6186f03..a2db887f 100644 >--- a/drivers/pci/probe.c >+++ b/drivers/pci/probe.c >@@ -923,7 +923,8 @@ static void pci_read_irq(struct pci_dev *dev) > dev->pin = irq; > if (irq) > pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq); >- dev->irq = irq; >+ if (irq < 255) >+ dev->irq = irq; > } > > void set_pcie_port_type(struct pci_dev *pdev) > -- David Härdeman -- 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: [RFC PATCH] usb/core: add current frame_number sysfs attr to hcd
On Tue, 19 Feb 2013, Stefan Tauner wrote: > Well, I am not entirely sure if even I want this in (as is) yet, > because it is just a part of a complete solution for my problem and I > can't imagine a reason why user space would want to know this odd > value as is. > So I can not give a committable rationale yet, but I can sum up what > I am trying to do eventually: I try to map SOF counters to > CLOCK_REALTIME timestamps in user space. Later I want to use that to > establish a global time base on microcontrollers connected via USB > without the hassle of running NTP or PTP over USB. In user space I am > waiting for changes in the frame_counter sysfs file by reading it and > comparing its contents to values previously read in a busy loop, which > is of course not very elegant but it works - apart from the fact that > the returned values are not the raw values (and as Alan noted, > might also be off a bit)... :) > > Therefore I am currently playing around with a > usb_hcd_get_real_frame_number() which uses a ehci_get_real_frame() > function hacked into ehci-hcd.c which returns the actual SOF counter > without the artificial horizon limit, but this is of course not > committable. I wonder though why the limitation is there in the first > place. Most users of usb_get_current_frame_number() seem rather unhappy > with the limitation (e.g. drivers/media/usb/uvc/uvc_video.c) or don't > care because they cap the returned value to the (locally defined(!)) > minimum of the schedule horizon (0xFF everywhere AFAICS). Only very few > use it directly to determine a possible scheduling (e.g. > drivers/isdn/hisax/st5481_d.c which looks rather dubious to my naive > eyes BTW). I wasn't aware that anyone was trying to use this API. In my opinion doing so is probably a mistake. In the future, all scheduling of periodic transfers will be done by the host controller driver; the upper-layer drivers won't have any choice in the matter. Hence they shouldn't care about the current frame number. (Note that drivers can still determine in which frames individual isochronous packets were sent. That information is available from urb->start_frame.) > So from the user's perspective I don't see a reason why the artificially > limited reply should be returned instead of the complete value. I have This was probably the result of some early design decisions which have not turned out well. > not checked if the raw value is available on all HCDs, but I assume it > is. Wouldn't it make sense to change usb_hcd_get_frame_number() to > return the raw value and add another one that returns the actual limit > of the schedule horizon e.g. periodic_size in the case of EHCI(?) for > those users that want to scheduler packets? Users should never want to schedule packets. > If not, I would really like to see the documentation of > usb_get_current_frame_number() be changed to make it more clear that it > is not the raw SOF value and *why*. I have not figured out what > *exactly* it is yet/how the iso scheduling works... grasping the kernel > - even a subsystem - is quite an effort :) If/when I do I will send a > documentation patch. It's going to get more complicated -- in one sense, that is: more complicated for the controller driver, but less complicated for everybody else. As far as I'm concerned, the usb_get_current_frame_number() API can be removed (unless somebody suggests a good use for it). > If you think refactoring get_frame_number should be done I would be > glad to work on it. A few pointers to what the result should look like > and any obvious pitfalls would be appreciated in that case. Using frame boundaries for time synchronization at the user level is possibly a defensible reason for exporting frame numbers. But there are better ways to accomplish this goal. For example, there could be an API that returns both a realtime value and a microframe number as of the next time a completion interrupt occurs. 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
qcaux: add Franklin U600
4 ports; AT/PPP is standard CDC-ACM. The other three (added by this patch) are QCDM/DIAG, possibly GPS, and unknown. Signed-off-by: Dan Williams --- diff --git a/drivers/usb/serial/qcaux.c b/drivers/usb/serial/qcaux.c index 9b1b96f..31f81c3 100644 --- a/drivers/usb/serial/qcaux.c +++ b/drivers/usb/serial/qcaux.c @@ -69,6 +69,7 @@ static struct usb_device_id id_table[] = { { USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfd, 0xff) }, /* NMEA */ { USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfe, 0xff) }, /* WMC */ { USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xff, 0xff) }, /* DIAG */ + { USB_DEVICE_AND_INTERFACE_INFO(0x1fac, 0x0151, 0xff, 0xff, 0xff) }, { }, }; MODULE_DEVICE_TABLE(usb, id_table); -- 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: Not enough resource for old configuration after USB bus reset
Hi all, I checkout the usb-next branch (on 2/18) and following the https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel. After reboot, the new kernel version is Linux dev 3.8.0-rc5-usbnext #1 SMP Mon Feb 18 18:04:02 CST 2013 i686 i686 i386 GNU/Linux. I try the same operation to produce the issue, and it also fails. Thanks, Soar -Original Message- From: Lan Tianyu [mailto:lantianyu1...@gmail.com] Sent: Friday, February 08, 2013 12:57 AM To: Soar Hung Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org Subject: Re: Not enough resource for old configuration after USB bus reset 于 2013/2/7 16:59, Soar Hung 写道: > Hi Tianyu, > > I can produce the issue on the Ubuntu 12.10 (linux 3.5), too. > > However, could you tell me more detail about what to do or give me some hint > for google? > Do you mean replacing the usb related source with source from 'usb next', > rebuild the kernel, and test again? > I think you can "git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git" and "git checkout usb-next". Compile kernel and test it. > Best regards, > Soar > > -Original Message- > From: Lan Tianyu [mailto:lantianyu1...@gmail.com] > Sent: Thursday, February 07, 2013 4:18 PM > To: Soar Hung > Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org > Subject: Re: Not enough resource for old configuration after USB bus > reset > > 2013/2/4 Soar Hung : >> Hi Alan, Sarah, >> >> Thank you for your kindly help. >> >> Can I do something to provide some help? >> > You found the issue on the 3.0.30+ kernel. Can you test it on the usb-next > branch of usb tree? Sarah has fixed a lot of bugs since v3.0. >> Best regards, >> Soar >> >> -Original Message- >> From: Alan Stern [mailto:st...@rowland.harvard.edu] >> Sent: Friday, February 01, 2013 11:36 PM >> To: Soar Hung >> Cc: Sarah Sharp; linux-usb@vger.kernel.org >> Subject: RE: Not enough resource for old configuration after USB bus >> reset >> >> On Fri, 1 Feb 2013, [big5] x R wrote: >> >>> Hi, >>> >>> According to xHCI spec Rev1 page 125, Endpoint context state diagram. >>> >>> When reset device, the endpoint state transit to disabled state. >>> >>> Do I make some mistake? >>> >>> I'll try to figure out the endopint state transitions during the reset >>> flow, and update information later. >>> >>> Thanks for the direction. >> >> Ah, now I understand the problem. The device reset automatically disables >> the endpoints, so when usb_reset_and_verify_device calls >> usb_hcd_alloc_bandwidth, and that routine tries to drop the endpoints, it >> fails because the endpoints are already disabled. >> >> Sarah is going to to have to figure out the right way to fix this. >> She's the maintainer for xhci-hcd. >> >> Alan Stern >> > > > > -- > Best regards > Tianyu Lan > > --Please consider the environment before printing this e-mail. > -- 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
[PATCH v2] qmi_wwan, cdc-ether: add ADU960S
It advertises a standard CDC-ETHER interface, which actually should be driven by qmi_wwan. Signed-off-by: Dan Williams --- index 3f3d12d..57136dc 100644 --- a/drivers/net/usb/cdc_ether.c +++ b/drivers/net/usb/cdc_ether.c @@ -615,6 +615,13 @@ static const struct usb_device_id products [] = { .driver_info = 0, }, +/* AnyDATA ADU960S - handled by qmi_wwan */ +{ + USB_DEVICE_AND_INTERFACE_INFO(0x16d5, 0x650a, USB_CLASS_COMM, + USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE), + .driver_info = 0, +}, + /* * WHITELIST!!! * diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 19d9035..efb5c7c 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -409,6 +409,13 @@ static const struct usb_device_id products[] = { USB_CDC_PROTO_NONE), .driver_info= (unsigned long)&qmi_wwan_info, }, + { /* ADU960S */ + USB_DEVICE_AND_INTERFACE_INFO(0x16d5, 0x650a, + USB_CLASS_COMM, + USB_CDC_SUBCLASS_ETHERNET, + USB_CDC_PROTO_NONE), + .driver_info= (unsigned long)&qmi_wwan_info, + }, /* 3. Combined interface devices matching on interface number */ {QMI_FIXED_INTF(0x0408, 0xea42, 4)},/* Yota / Megafon M100-1 */ -- 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 v2] qmi_wwan, cdc-ether: add ADU960S
From: Dan Williams Date: Mon, 18 Feb 2013 21:25:09 -0600 > It advertises a standard CDC-ETHER interface, which actually should be > driven by qmi_wwan. > > Signed-off-by: Dan Williams Applied. -- 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 v2 1/5] drivers: phy: add generic PHY framework
The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has describes the PHY (label, type etc..) and ops like init, exit, suspend, resume, poweron, shutdown. The documentation for the generic PHY framework is added in Documentation/phy.txt and the documentation for the sysfs entry is added in Documentation/ABI/testing/sysfs-class-phy. Signed-off-by: Kishon Vijay Abraham I --- Documentation/ABI/testing/sysfs-class-phy | 15 + Documentation/phy.txt | 113 +++ MAINTAINERS |7 + drivers/Kconfig |2 + drivers/Makefile |2 + drivers/phy/Kconfig | 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c| 519 + include/linux/phy/phy.h | 198 +++ 9 files changed, 874 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-phy create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h diff --git a/Documentation/ABI/testing/sysfs-class-phy b/Documentation/ABI/testing/sysfs-class-phy new file mode 100644 index 000..ffd9930 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-phy @@ -0,0 +1,15 @@ +What: /sys/class/phy//label +Date: Feb 2013 +KernelVersion: 3.10 +Contact: Kishon Vijay Abraham I +Description: + This is a read-only file for getting the label of the phy. + +What: /sys/class/phy//bind +Date: Feb 2013 +KernelVersion: 3.10 +Contact: Kishon Vijay Abraham I +Description: + This is a read-only file for reading the phy binding + information. It contains the device name of the controller, + the index and the device name of the PHY in that order. diff --git a/Documentation/phy.txt b/Documentation/phy.txt new file mode 100644 index 000..a850aa0 --- /dev/null +++ b/Documentation/phy.txt @@ -0,0 +1,113 @@ + The Generic PHY Framework + Kishon Vijay Abraham I + +This document explains the Generic PHY Framework along with the APIs provided, +how-to-use, current status and the future work list. + +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controller has PHY functionality embedded into it and others use an external +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet, +SATA etc. + +The intention of creating this framework is to bring the phy drivers spread +all over the Linux kernel to drivers/phy to increase code re-use and to +increase code maintainability. + +This framework will be of use only to devices that uses external PHY (PHY +functionality is not embedded within the controller). + +2. Creating the PHY + +The PHY driver should create the PHY in order for other peripheral controllers +to make use of it. The PHY framework provides 2 APIs to create the PHY. + +struct phy *phy_create(struct device *dev, struct phy_descriptor *desc); +struct phy *devm_phy_create(struct device *dev, struct phy_descriptor *desc); + +The PHY drivers can use one of the above 2 APIs to create the PHY by passing +the device pointer and the phy_descriptor. phy_descriptor is a structure that +contains information about the PHY such as label, type, bus_type and phy_ops. +phy_ops is a set of function pointers for performing PHY operations such as +init, exit, suspend, resume, poweron and shutdown. + +3. Binding the PHY to the controller + +The framework provides an API for binding the controller to the PHY in the +case of non dt boot. + +struct phy_bind *phy_bind(const char *dev_name, u8 index, + const char *phy_dev_name); + +The API fills the phy_bind structure with the dev_name (device name of the +controller), index and phy_dev_name (device name of the PHY). This will +be used when the controller requests this phy. This API should be used by +platform specific initialization code (board file). + +In the case of dt boot, the binding in
[PATCH v2 2/5] usb: phy: omap-usb2: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. omap_usb2_suspend is split into omap_usb_suspend and omap_usb_resume in order to align with the new framework. However using the old USB PHY library cannot be completely removed because OTG is intertwined with PHY and moving to the new framework will break OTG. Once we have a separate OTG state machine, we can get rid of the USB PHY library. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/phy/omap-usb2.c | 49 ++ include/linux/usb/omap_usb.h |3 +++ 2 files changed, 52 insertions(+) diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c index 844ab68..924ae59 100644 --- a/drivers/usb/phy/omap-usb2.c +++ b/drivers/usb/phy/omap-usb2.c @@ -119,9 +119,48 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend) return 0; } +static int omap_usb_suspend(struct phy_descriptor *desc) +{ + struct omap_usb *phy = desc_to_omapusb(desc); + + if (!phy->is_suspended) { + omap_control_usb_phy_power(phy->control_dev, 0); + pm_runtime_put_sync(phy->dev); + phy->is_suspended = 1; + } + + return 0; +} + +static int omap_usb_resume(struct phy_descriptor *desc) +{ + u32 ret; + struct omap_usb *phy = desc_to_omapusb(desc); + + if (phy->is_suspended) { + ret = pm_runtime_get_sync(phy->dev); + if (ret < 0) { + dev_err(phy->dev, "get_sync failed with err %d\n", + ret); + return ret; + } + omap_control_usb_phy_power(phy->control_dev, 1); + phy->is_suspended = 0; + } + + return 0; +} + +static struct phy_ops ops = { + .suspend= omap_usb_suspend, + .resume = omap_usb_resume, + .owner = THIS_MODULE, +}; + static int omap_usb2_probe(struct platform_device *pdev) { struct omap_usb *phy; + struct phy *generic_phy; struct usb_otg *otg; phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL); @@ -144,6 +183,16 @@ static int omap_usb2_probe(struct platform_device *pdev) phy->phy.otg= otg; phy->phy.type = USB_PHY_TYPE_USB2; + phy->desc.ops = &ops; + phy->desc.label = "omap-usb2"; + phy->desc.of_node = pdev->dev.of_node; + + generic_phy = devm_phy_create(phy->dev, &phy->desc); + if (IS_ERR(generic_phy)) { + dev_dbg(&pdev->dev, "Failed to create PHY\n"); + return PTR_ERR(generic_phy); + } + phy->control_dev = omap_get_control_dev(); if (IS_ERR(phy->control_dev)) { dev_dbg(&pdev->dev, "Failed to get control device\n"); diff --git a/include/linux/usb/omap_usb.h b/include/linux/usb/omap_usb.h index 6ae2936..4c6878e 100644 --- a/include/linux/usb/omap_usb.h +++ b/include/linux/usb/omap_usb.h @@ -20,6 +20,7 @@ #define __DRIVERS_OMAP_USB2_H #include +#include #include struct usb_dpll_params { @@ -32,6 +33,7 @@ struct usb_dpll_params { struct omap_usb { struct usb_phy phy; + struct phy_descriptor desc; struct phy_companion*comparator; void __iomem*pll_ctrl_base; struct device *dev; @@ -43,6 +45,7 @@ struct omap_usb { }; #definephy_to_omapusb(x) container_of((x), struct omap_usb, phy) +#definedesc_to_omapusb(x) container_of((x), struct omap_usb, desc) #if defined(CONFIG_OMAP_USB2) || defined(CONFIG_OMAP_USB2_MODULE) extern int omap_usb2_set_comparator(struct phy_companion *comparator); -- 1.7.10.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
[PATCH v2 3/5] usb: otg: twl4030: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. twl4030_usb_suspend and twl4030_usb_resume is added to phy_ops in order to align with the new framework. However using the old USB PHY library cannot be completely removed because OTG is intertwined with PHY and moving to the new framework completely will break OTG. Once we have a separate OTG state machine, we can get rid of the USB PHY library. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/otg/twl4030-usb.c | 41 + 1 file changed, 41 insertions(+) diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c index a994715..b79c319 100644 --- a/drivers/usb/otg/twl4030-usb.c +++ b/drivers/usb/otg/twl4030-usb.c @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -145,6 +146,7 @@ struct twl4030_usb { struct usb_phy phy; + struct phy_descriptor desc; struct device *dev; /* TWL4030 internal USB regulator supplies */ @@ -167,6 +169,7 @@ struct twl4030_usb { /* internal define on top of container_of */ #define phy_to_twl(x) container_of((x), struct twl4030_usb, phy) +#define desc_to_twl(x) container_of((x), struct twl4030_usb, desc) /*-*/ @@ -575,10 +578,38 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host) return 0; } +static int twl4030_usb_suspend(struct phy_descriptor *desc) +{ + struct twl4030_usb *twl = desc_to_twl(desc); + + twl4030_phy_suspend(twl, 1); + + return 0; +} + +static int twl4030_usb_resume(struct phy_descriptor *desc) +{ + struct twl4030_usb *twl = desc_to_twl(desc); + + if (!twl->asleep) + return -EBUSY; + __twl4030_phy_resume(twl); + twl->asleep = 0; + + return 0; +} + +static struct phy_ops ops = { + .suspend= twl4030_usb_suspend, + .resume = twl4030_usb_resume, + .owner = THIS_MODULE, +}; + static int twl4030_usb_probe(struct platform_device *pdev) { struct twl4030_usb_data *pdata = pdev->dev.platform_data; struct twl4030_usb *twl; + struct phy *phy; int status, err; struct usb_otg *otg; struct device_node *np = pdev->dev.of_node; @@ -617,6 +648,16 @@ static int twl4030_usb_probe(struct platform_device *pdev) otg->set_host = twl4030_set_host; otg->set_peripheral = twl4030_set_peripheral; + twl->desc.ops = &ops; + twl->desc.label = "twl4030"; + twl->desc.of_node = pdev->dev.of_node; + + phy = devm_phy_create(twl->dev, &twl->desc); + if (IS_ERR(phy)) { + dev_dbg(&pdev->dev, "Failed to create PHY\n"); + return PTR_ERR(phy); + } + /* init spinlock for workqueue */ spin_lock_init(&twl->lock); -- 1.7.10.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
[PATCH v2 0/5] Generic PHY Framework
Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Changes from v1: * Added Documentation for the PHY framework * Added few more APIs mostly w.r.t devres * Modified omap-usb2 and twl4030 to make use of the new framework Did USB enumeration testing in panda and beagle. Kishon Vijay Abraham I (5): drivers: phy: add generic PHY framework usb: phy: omap-usb2: use the new generic PHY framework usb: otg: twl4030: use the new generic PHY framework ARM: OMAP: USB: Add phy binding information usb: musb: omap2430: use the new generic PHY framework Documentation/ABI/testing/sysfs-class-phy| 15 + Documentation/phy.txt| 113 ++ MAINTAINERS |7 + arch/arm/mach-omap2/board-2430sdp.c |2 + arch/arm/mach-omap2/board-3430sdp.c |2 + arch/arm/mach-omap2/board-4430sdp.c |2 + arch/arm/mach-omap2/board-cm-t35.c |2 + arch/arm/mach-omap2/board-devkit8000.c |2 + arch/arm/mach-omap2/board-igep0020.c |2 + arch/arm/mach-omap2/board-ldp.c |2 + arch/arm/mach-omap2/board-omap3beagle.c |2 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3logic.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |2 + arch/arm/mach-omap2/board-omap3touchbook.c |2 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c|2 + arch/arm/mach-omap2/board-rm680.c|2 + arch/arm/mach-omap2/board-zoom-peripherals.c |2 + drivers/Kconfig |2 + drivers/Makefile |2 + drivers/phy/Kconfig | 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 519 ++ drivers/usb/musb/musb_core.h |2 + drivers/usb/musb/omap2430.c | 22 +- drivers/usb/otg/twl4030-usb.c| 41 ++ drivers/usb/phy/omap-usb2.c | 49 +++ include/linux/phy/phy.h | 198 ++ include/linux/usb/omap_usb.h |3 + 31 files changed, 1019 insertions(+), 6 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-phy create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h -- 1.7.10.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
[PATCH v2 4/5] ARM: OMAP: USB: Add phy binding information
In order for controllers to get PHY in case of non dt boot, the phy binding information should be added in the platform specific initialization code using phy_bind. The previously added usb_bind_phy can't be removed yet because the musb controller continues to use the old PHY library which has OTG in it (struct usb_phy has struct usb_otg as member). Until we have a separate OTG state machine to handle all of that, the new generic PHY framework and the old phy library will co-exist. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/mach-omap2/board-2430sdp.c |2 ++ arch/arm/mach-omap2/board-3430sdp.c |2 ++ arch/arm/mach-omap2/board-4430sdp.c |2 ++ arch/arm/mach-omap2/board-cm-t35.c |2 ++ arch/arm/mach-omap2/board-devkit8000.c |2 ++ arch/arm/mach-omap2/board-igep0020.c |2 ++ arch/arm/mach-omap2/board-ldp.c |2 ++ arch/arm/mach-omap2/board-omap3beagle.c |2 ++ arch/arm/mach-omap2/board-omap3evm.c |2 ++ arch/arm/mach-omap2/board-omap3logic.c |2 ++ arch/arm/mach-omap2/board-omap3pandora.c |2 ++ arch/arm/mach-omap2/board-omap3stalker.c |2 ++ arch/arm/mach-omap2/board-omap3touchbook.c |2 ++ arch/arm/mach-omap2/board-omap4panda.c |2 ++ arch/arm/mach-omap2/board-overo.c|2 ++ arch/arm/mach-omap2/board-rm680.c|2 ++ arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++ 17 files changed, 34 insertions(+) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 1337f2c..a28cc5b 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include @@ -265,6 +266,7 @@ static void __init omap_2430sdp_init(void) omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP); usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); + phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb"); usb_musb_init(NULL); board_smc91x_init(); diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 8a2e242..a4f4b8e 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include @@ -581,6 +582,7 @@ static void __init omap_3430sdp_init(void) omap_serial_init(); omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL); usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); + phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb"); usb_musb_init(NULL); board_smc91x_init(); board_flash_init(sdp_flash_partitions, chip_sel_3430, 0); diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 8e8efcc..d5bc353 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include @@ -698,6 +699,7 @@ static void __init omap_4430sdp_init(void) omap4_twl6030_hsmmc_init(mmc); usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); + phy_bind("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); usb_musb_init(&musb_board_data); status = omap_ethernet_init(); diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index f1172f2..6860dc9 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include @@ -726,6 +727,7 @@ static void __init cm_t3x_common_init(void) omap_twl4030_audio_init("cm-t3x"); usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); + phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb"); usb_musb_init(NULL); cm_t35_init_usbh(); cm_t35_init_camera(); diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c index 77cade52..89c3e64 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include @@ -624,6 +625,7 @@ static void __init devkit8000_init(void) omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL); usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb"); + phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb"); usb_musb_init(NULL); usbhs_init(&usbhs_bdata); board_nand_init(devkit8000_nand_partitions, diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c index 15e5881..2ef8b31 100644 --- a/arch/arm/mach-omap2/board-igep0020.c +++ b/arch/arm/mach-omap2/board-igep0020.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -627,6 +628,7 @@ static void __init igep_init(void)
[PATCH v2 5/5] usb: musb: omap2430: use the new generic PHY framework
Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend and usb_phy_set_resume is replaced with phy_suspend and phy_resume to align with the new PHY framework. musb->xceiv can't be removed as of now because musb core uses xceiv.state and xceiv.otg. Once there is a separate state machine to handle otg, these can be moved out of xceiv and then we can start using the generic PHY framework. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/musb/musb_core.h |2 ++ drivers/usb/musb/omap2430.c | 22 -- 2 files changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h index 7fb4819..78251fd 100644 --- a/drivers/usb/musb/musb_core.h +++ b/drivers/usb/musb/musb_core.h @@ -46,6 +46,7 @@ #include #include #include +#include struct musb; struct musb_hw_ep; @@ -357,6 +358,7 @@ struct musb { u16 int_tx; struct usb_phy *xceiv; + struct phy *phy; int nIrq; unsignedirq_wake:1; diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 1762354..99378af 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -345,14 +345,24 @@ static int omap2430_musb_init(struct musb *musb) * up through ULPI. TWL4030-family PMICs include one, * which needs a driver, drivers aren't always needed. */ - if (dev->parent->of_node) + if (dev->parent->of_node) { + musb->phy = devm_of_phy_get(dev->parent, "usb-phy", 0); + + /* We can't totally remove musb->xceiv as of now because +* musb core uses xceiv.state and xceiv.otg. Once we have +* a separate state machine to handle otg, these can be moved +* out of xceiv and then we can start using the generic PHY +* framework +*/ musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent, "usb-phy", 0); - else + } else { musb->xceiv = devm_usb_get_phy_dev(dev, 0); + musb->phy = devm_phy_get(dev, 0); + } - if (IS_ERR_OR_NULL(musb->xceiv)) { - pr_err("HS USB OTG: no transceiver configured\n"); + if (IS_ERR_OR_NULL(musb->xceiv) || IS_ERR_OR_NULL(musb->phy)) { + dev_err(dev, "no transceiver configured\n"); return -EPROBE_DEFER; } @@ -608,7 +618,7 @@ static int omap2430_runtime_suspend(struct device *dev) OTG_INTERFSEL); omap2430_low_level_exit(musb); - usb_phy_set_suspend(musb->xceiv, 1); + phy_suspend(musb->phy); } return 0; @@ -624,7 +634,7 @@ static int omap2430_runtime_resume(struct device *dev) musb_writel(musb->mregs, OTG_INTERFSEL, musb->context.otg_interfsel); - usb_phy_set_suspend(musb->xceiv, 0); + phy_resume(musb->phy); } return 0; -- 1.7.10.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 2/2] USB: EHCI: make ehci-orion a separate driver
On Mon, Feb 18, 2013 at 05:34:35PM -0500, Alan Stern wrote: > On Fri, 15 Feb 2013, Arnd Bergmann wrote: > > > From: Manjunath Goudar > > > > With the multiplatform changes in arm-soc tree, it becomes > > possible to enable the mvebu platform (which uses > > ehci-orion) at the same time as other platforms that require > > a conflicting EHCI bus glue. At the moment, this results > > in a warning like > > > > drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined > > [enabled by default] > > drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the > > previous definition > > drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined > > but not used [-Wunused-variable] > > > > and an ehci driver that only works on one of them. > > > > With the infrastructure added by Alan Stern in patch 3e0232039 > > "USB: EHCI: prepare to make ehci-hcd a library module", we can > > avoid this problem by turning a bus glue into a separate > > module, as we do here for the orion bus glue. > > > --- a/drivers/usb/host/Makefile > > +++ b/drivers/usb/host/Makefile > > @@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o > > > > obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o > > obj-$(CONFIG_USB_EHCI_HCD_VT8500)+= ehci-vt8500.o > > +obj-$(CONFIG_USB_EHCI_HCD_ORION)+= ehci-orion.o > > Both of these two new lines should be formatted like the other lines in > this file (i.e., with tabs at the corresponding places), and they > should come before the OXU210HP_HCD entry so that they are next to the > other EHCI-related lines. > > > --- a/drivers/usb/host/ehci-orion.c > > +++ b/drivers/usb/host/ehci-orion.c > > @@ -17,6 +17,13 @@ > > #include > > #include > > #include > > +#include > > +#include > > +#include > > +#include > > Is this line really needed? > > > @@ -34,6 +41,17 @@ > > #define USB_PHY_IVREF_CTRL 0x440 > > #define USB_PHY_TST_GRP_CTRL 0x450 > > > > +#define DRIVER_DESC "EHCI orion driver" > > + > > +static const char hcd_name[] = "ehci-orion"; > > + > > +static struct hc_driver __read_mostly ehci_orion_hc_driver; > > + > > +static const struct ehci_driver_overrides orion_overrides __initdata = { > > + .reset = ehci_setup, > > +}; > > This is not necessary; ehci_setup is the default value anyway. This > structure can be omitted. > > > @@ -323,8 +296,6 @@ static int __exit ehci_orion_drv_remove(struct > > platform_device *pdev) > > return 0; > > } > > > > -MODULE_ALIAS("platform:orion-ehci"); > > - > > static const struct of_device_id ehci_orion_dt_ids[] = { > > { .compatible = "marvell,orion-ehci", }, > > {}, > > @@ -336,8 +307,31 @@ static struct platform_driver ehci_orion_driver = { > > .remove = __exit_p(ehci_orion_drv_remove), > > .shutdown = usb_hcd_platform_shutdown, > > .driver = { > > - .name = "orion-ehci", > > + .name = hcd_name, > > Is this really what you want -- changing the driver name from > "orion-ehci" to "ehci-orion"? Is that liable to cause trouble? > > > +MODULE_DESCRIPTION(DRIVER_DESC); > > +MODULE_ALIAS("platform:ehci-orion"); > > And is this really what you want -- changing the alias from > "platform:orion-ehci" to "platform:ehci-orion"? Hi Manjunath I can confirm that this breaks non DT based kirkwood systems. The driver does not get loaded. Sorry for not testing and finding this case earlier, i just tested a DT based system. GregKH: Please can you drop this patch from usb-next. It breaks more than it fixes. Andrew -- 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: [regression][v3.8rc6->v3.8rc7] ehci-pci fails with error -110 on read/[64,all]
Correction, this regression/commit (55bcdce) was introduced between rc6 and rc7. Sorry about that. 2013/2/18 Ronald : > CC'ing the author of the patch. > > 2013/2/18 Ronald : > This e-mail is a follow-up as requested in this bug[1]. I will repost > everything so far in this e-mail. Please CC me as I'm not subscribed > to your list. > > Current head gives this when I plug a 'Mass Storage Device' into a 2.0 > hub: > > [ 842.760400] hub 1-0:1.0: unable to enumerate USB device on port 3 > [ 843.080058] usb 1-3: new high-speed USB device number 48 using ehci-pci > [ 858.230072] usb 1-3: device descriptor read/64, error -110 > [ 873.490070] usb 1-3: device descriptor read/64, error -110 > > Reverting the following commit makes it work again: > > commit 55bcdce8a8228223ec4d17d8ded8134ed265d2c5 > Author: Alan Stern > Date: Fri Jan 25 16:52:45 2013 -0500 > > USB: EHCI: remove ASS/PSS polling timeout > > This patch (as1647) attempts to work around a problem that seems to > affect some nVidia EHCI controllers. They sometimes take a very long > time to turn off their async or periodic schedules. I don't know if > this is a result of other problems, but in any case it seems wise not > to depend on schedule enables or disables taking effect in any > specific length of time. > > The patch removes the existing 20-ms timeout for enabling and > disabling the schedules. The driver will now continue to poll the > schedule state at 1-ms intervals until the controller finally decides > to obey the most recent command issued by the driver. Just in case > this hides a problem, a debugging message will be logged if the > controller takes longer than 20 polls. > > I don't know if this will actually fix anything, but it can't hurt. > > Signed-off-by: Alan Stern > Tested-by: Piergiorgio Sartor > CC: > Signed-off-by: Greg Kroah-Hartman > > diff --git a/drivers/usb/host/ehci-timer.c b/drivers/usb/host/ehci-timer.c > index 20dbdcb..f904071 100644 > --- a/drivers/usb/host/ehci-timer.c > +++ b/drivers/usb/host/ehci-timer.c > @@ -113,14 +113,15 @@ static void ehci_poll_ASS(struct ehci_hcd *ehci) > > if (want != actual) { > > - /* Poll again later, but give up after about 20 ms */ > - if (ehci->ASS_poll_count++ < 20) { > - ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, > true); > - return; > - } > - ehci_dbg(ehci, "Waited too long for the async schedule > status(%x/%x), giving up\n", > - want, actual); > + /* Poll again later */ > + ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true); > + ++ehci->ASS_poll_count; > + return; > } > + > + if (ehci->PSS_poll_count > 20) > + ehci_dbg(ehci, "PSS poll count reached %d\n", > + ehci->PSS_poll_count); > ehci->PSS_poll_count = 0; > > /* The status is up-to-date; restart or stop the schedule as > needed */ > > Please note, that I'm using the 'irqpoll' cmdline to improve system > stability. What I forgot to mention in the bug was the chipset: > > 00:10.3 USB controller: VIA Technologies, Inc. USB 2.0 (rev 82) > (prog-if 20 [EHCI]) > Subsystem: Micro-Star International Co., Ltd. KT4AV motherboard > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- > ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32, Cache Line Size: 32 bytes > Interrupt: pin D routed to IRQ 21 > Region 0: Memory at dffeff00 (32-bit, non-prefetchable) [size=256] > Capabilities: [80] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA > PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Kernel driver in use: ehci-pci > > Yes, it's 10 years old, and no I'm not scrooge. We are waiting a while > for computer prices to plummet mkay? > > [1]: https://bugzilla.kernel.org/show_bug.cgi?id=54031 Would like to add that while searching the mailing lists I stumbled on this: http://marc.info/?l=linux-usb&m=136045531311402&w=4 It's an entirely seperate USB issue in this cycle. The person is doing git bisect to find the regression. I did another approach as recompiling the full kernel on a 1,25GHz isn't even remotely funny anym
Re: ->drop_endpoint being called for disabled endpoints
Hi, On Mon, Feb 18, 2013 at 05:20:44PM -0500, Alan Stern wrote: > On Fri, 15 Feb 2013, Felipe Balbi wrote: > > > Hi all, > > > > I keep seeing the following messages when transferring data to any USB3 > > mass storage I have (tried 3 different ones already): > > > > [618002.014556] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with > > disabled ep 88012976cd40 > > [618002.014562] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with > > disabled ep 88012976cd80 > > > > It looks like usbcore is calling ->drop_endpoint() for endpoints which > > are already disabled. I wonder if that's something legal to do or if we > > want to protect calls to ->drop_endpoint() with if (ep->enabled) check. > > There was a thread on this topic a couple of weeks ago: > > http://marc.info/?t=13587409252&r=1&w=2 > > Device resets cause the hardware to disable the endpoint rings, but > apparently xhci-hcd doesn't take this into account. Hence it ends up > trying to drop endpoints which are already disabled, causing those > error messages. > > > I'll add a WARN_ONCE() later just to check who's to blame here, but it's > > a pretty annoying message to see all the time. :-) > > > > How about something like below ? > > No, I think this needs to be fixed in xhci-hcd. fair enough, though I think the issue is two-fold: a) on reset xhci-hcd should set ep->enabled to zero b) patch I sent should still be applied no ? -- balbi signature.asc Description: Digital signature