Re: [PATCH 0/3] palmas usb driver
Hi Felipe, On Tuesday 28 May 2013 11:05 PM, Felipe Balbi wrote: On Fri, May 24, 2013 at 08:01:33PM +0530, Kishon Vijay Abraham I wrote: This patch series adds driver for palmas usb which is used to detect attach/detach events of usb device and usb host. [PATCH v5 2/3] extcon: Palmas Extcon Driver which was sent previously is added in this patch series itself. The revision history is added in the patch comments section. A checkpatch warning WARNING: static const char * array should probably be static const char * constis ignored since it introduces a compilation warning. Graeme Gregory (2): drivers: regulator: palmas: add an API to set/clear the switch bit on SMPS10 extcon: Palmas Extcon Driver Kishon Vijay Abraham I (1): usb: dwc3: use extcon fwrk to receive connect/disconnect notification There were some comments to this series, what will happen with it ? Any new versions coming ? I've already sent new versions. Palmas Extcon Driver is already queued in extcon-next. Chanwoo can take this patch in his tree after your ACK. [PATCH v2] usb: dwc3: use extcon fwrk to receive connect/disconnect notification. 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: [PATCH] usb: dwc3: cleanup DWC3_DCTL_LSFTRST bit
Hi Felipe, On Wed, May 29, 2013 at 01:25:59AM +0800, Felipe Balbi wrote: On Tue, May 28, 2013 at 03:42:50PM +0800, Huang Rui wrote: This bit is removed and set as reserved in 2.50a spec. Signed-off-by: Huang Rui ray.hu...@amd.com so ? This driver also works on older versions of the core. What you should do is, perhaps, add a comment saying that this bit shouldn't be used in v2.50a+, then we need to keep an eye for any future users of that bit and make sure that there is proper revision detection around it. Thanks to your reply. I greped codes, in current driver didn't use this bit, and I saw that the bit is marked as reserved in 2.50a spec. I don't confirm this bit should use in v2.50a+, if it will be used or I was wrong, please correct me. I just looked at register mapping, and compared with spec and found this bit is reserved, so I send this patch to remove this define to prevent to confuse. :) Best Regards, Rui -- 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: dwc3: omap Modify dwc3_omap_readl/writel with offsets
-Original Message-
From: Balbi, Felipe
Sent: Tuesday, May 28, 2013 11:02 PM
To: Cherian, George
Cc: Balbi, Felipe; linux-usb@vger.kernel.org; linux-o...@vger.kernel.org;
linux-ker...@vger.kernel.org; gre...@linuxfoundation.org
Subject: Re: [PATCH 3/3] usb: dwc3: omap Modify dwc3_omap_readl/writel
with offsets
Hi,
On Mon, May 27, 2013 at 01:32:57PM +0530, George Cherian wrote:
This patch modifies dwc3_omap_readl/writel calls to accomodate
both OMAP5 and AM437x reg maps (It uses the cached register offsets).
Also renames OMAP5 IRQ1 as IRQMISC, IRQ1 bits as IRQMISC bits.
Signed-off-by: George Cherian george.cher...@ti.com
can you change this patch a bit so that it adds wrappers around
dwc3_omap_*() ? The idea is the have the code look like:
static u32 dwc3_omap_read_utmi_status(struct dwc3_omap *omap)
{
return dwc3_omap_readl(omap-base,
USBOTGSS_UTMI_OTG_STATUS +
omap-utmi_otg_offset);
}
(likewise for write and for all other offsets, of course)
that way, reading/writing to registers which need the offset will be
less error-prone and th driver will look a little nicer.
Yes , I will do it in next version.
--
Balbi
-George
--
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
Chipidea usb otg support for IMX/MXS (device functionality)
Hello, Am I right in assuming that the MXS USB on-the-go port does not currently support the device (gadget) functionality? Anybody out there working on that? Regards, -- Héctor Palacios -- 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: Chipidea usb otg support for IMX/MXS (device functionality)
Hello, Am I right in assuming that the MXS USB on-the-go port does not currently support the device (gadget) functionality? Anybody out there working on that? As far as I know, Maxime Ripard may already let the chipidea durl-role function work ok at mx28. It may need my chipidea otg patch https://github.com/hzpeterchen/linux-usb.git Peter -- 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] net/usb/kalmia: use %*phC to dump small buffers
Instead of dereferencing pointer and put values on stack we could use nice
%*phC specifier.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
Since v1:
- don't split message strings
drivers/net/usb/kalmia.c | 45 +++--
1 file changed, 15 insertions(+), 30 deletions(-)
diff --git a/drivers/net/usb/kalmia.c b/drivers/net/usb/kalmia.c
index 0192073..6866eae 100644
--- a/drivers/net/usb/kalmia.c
+++ b/drivers/net/usb/kalmia.c
@@ -221,12 +221,9 @@ done:
memset(skb_put(skb, padlen), 0, padlen);
}
- netdev_dbg(
- dev-net,
- Sending package with length %i and padding %i. Header:
%02x:%02x:%02x:%02x:%02x:%02x.,
- content_len, padlen, header_start[0], header_start[1],
- header_start[2], header_start[3], header_start[4],
- header_start[5]);
+ netdev_dbg(dev-net,
+ Sending package with length %i and padding %i. Header: %6phC.,
+ content_len, padlen, header_start);
return skb;
}
@@ -263,32 +260,23 @@ kalmia_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
sizeof(EXPECTED_UNKNOWN_HEADER_1)) || !memcmp(
header_start, EXPECTED_UNKNOWN_HEADER_2,
sizeof(EXPECTED_UNKNOWN_HEADER_2))) {
- netdev_dbg(
- dev-net,
- Received expected unknown frame
header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n,
- header_start[0], header_start[1],
- header_start[2], header_start[3],
- header_start[4], header_start[5],
+ netdev_dbg(dev-net,
+ Received expected unknown frame
header: %6phC. Package length: %i\n,
+ header_start,
skb-len - KALMIA_HEADER_LENGTH);
}
else {
- netdev_err(
- dev-net,
- Received unknown frame header:
%02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n,
- header_start[0], header_start[1],
- header_start[2], header_start[3],
- header_start[4], header_start[5],
+ netdev_err(dev-net,
+ Received unknown frame header: %6phC.
Package length: %i\n,
+ header_start,
skb-len - KALMIA_HEADER_LENGTH);
return 0;
}
}
else
- netdev_dbg(
- dev-net,
- Received header:
%02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n,
- header_start[0], header_start[1],
header_start[2],
- header_start[3], header_start[4],
header_start[5],
- skb-len - KALMIA_HEADER_LENGTH);
+ netdev_dbg(dev-net,
+ Received header: %6phC. Package length: %i\n,
+ header_start, skb-len - KALMIA_HEADER_LENGTH);
/* subtract start header and end header */
usb_packet_length = skb-len - (2 * KALMIA_HEADER_LENGTH);
@@ -310,12 +298,9 @@ kalmia_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
sizeof(HEADER_END_OF_USB_PACKET)) == 0);
if (!is_last) {
header_start = skb-data + ether_packet_length;
- netdev_dbg(
- dev-net,
- End header:
%02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n,
- header_start[0], header_start[1],
- header_start[2], header_start[3],
- header_start[4], header_start[5],
+ netdev_dbg(dev-net,
+ End header: %6phC. Package length:
%i\n,
+ header_start,
skb-len - KALMIA_HEADER_LENGTH);
}
}
--
1.8.2.rc0.22.gb3600c3
--
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] net/usb/kalmia: use %*phC to dump small buffers
From: Andy Shevchenko andriy.shevche...@linux.intel.com Date: Wed, 29 May 2013 10:22:30 +0300 Instead of dereferencing pointer and put values on stack we could use nice %*phC specifier. Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com Applied, thanks. -- 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: Chipidea usb otg support for IMX/MXS (device functionality)
Hi, On Wed, May 29, 2013 at 07:11:30AM +, Chen Peter-B29397 wrote: Hello, Am I right in assuming that the MXS USB on-the-go port does not currently support the device (gadget) functionality? Anybody out there working on that? As far as I know, Maxime Ripard may already let the chipidea durl-role function work ok at mx28. It may need my chipidea otg patch https://github.com/hzpeterchen/linux-usb.git Indeed, I've been using the patchset Add tested id switch and vbus connect detect support for Chipidea from Peter for quite some time on top of 3.9 and it works like a charm for the gadget mode on an MX28 platform. BTW, Peter, I've seen that these patches are still not merged in 3.10, is there a reason for that? do you plan on sending a version rebased on top of 3.10 some time in the future? I tried to do the rebasing myself, but the chipidea driver seems to have changed quite heavily, which makes the process quite difficult when you don't know what you're doing :) Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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: Chipidea usb otg support for IMX/MXS (device functionality)
Indeed, I've been using the patchset Add tested id switch and vbus connect detect support for Chipidea from Peter for quite some time on top of 3.9 and it works like a charm for the gadget mode on an MX28 platform. BTW, Peter, I've seen that these patches are still not merged in 3.10, is there a reason for that? do you plan on sending a version rebased on top of 3.10 some time in the future? I tried to do the rebasing myself, but the chipidea driver seems to have changed quite heavily, which makes the process quite difficult when you don't know what you're doing :) I can spend few bandwidth on upstream work recently, I may have more bandwidth after June 15th. Currently, we still have no conclusion for chipidea core driver's coming work, like Device tree support, how to identify if the controller is OTG supported. Best regards, Peter -- 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
Some questions about Xhci bulk protocol streaming
hi all and Sarah: I have some questions about xhci bulk transfer streaming protocol in linux. i bought a device which declare it support USB Attached SCSI Protocol. (please reference the attach descriptor) and from below link, the kernel will support this transfer once I insert uas.ko. https://lkml.org/lkml/2011/4/25/26 But I cannot record any stream protocol from catc analyzer. Should I open any other kernel config instead of only inserting uas.ko? Thanks for your great help, uasp.devices.desc Description: Binary data
Re: USB3 SSD/HD device file disappears after eject
Hi, On 29.05.2013 05:32, Grant wrote: [...] sd 8:0:0:0: [sdb] Synchronizing SCSI cache sd 8:0:0:0: Device offlined - not ready after error recovery Unplugging and replugging the device does not result in the reappearance of the /dev/sdb device file like it does with my other external drives. The only way to bring the /dev/sdb device file back is to 'modprobe -r xhci_hcd modprobe xhci_hcd'. [...] I'm not sure where the problem is exactly but I think it is really a problem with the power down of some USB hardware in the chain. I am wondering why this still exists on your quite new hardware. I see this here on my own (a few years old) laptop with experimenting some power control settings. I think your USB port got power switched off and so can't detect that you have re-plugged a new device. So my idea is, with reloading the kernel module the power is switched on again. Maybe there should be a config option in userspace to disable powerdown and only unmount filesystems if it is not possible to detect powerdown support of hardware?! Best regards, Markus -- 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] usb: musb: fix clock naming
On Wed, May 29, 2013 at 11:36 AM, Jan Lübbe j...@pengutronix.de wrote: On Tue, 2013-05-28 at 20:36 +0300, Felipe Balbi wrote: On Tue, May 28, 2013 at 09:21:01AM +0200, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com 'ick' was changed to 'hsotgusb_ick' 'fck' was changed to 'hsotgusb_fck' Signed-off-by: Jan Luebbe j...@pengutronix.de Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com NAK. Fix your clock data. Yegor, I'm not sure how my signed-off-by got here. It seems that you picked the patch up from this thread: http://marc.info/?l=linux-omapm=134390141101734 Note that my mail contains no signed-off-by and the change is described as a work around. I'll remove your SoB, when I post the next version. I just added it, because you provided the fix. Will contact you next time first. Have you worked on this SoC lately? Any pending patches? Yegor -- 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] usb: musb: fix clock naming
On Tue, May 28, 2013 at 7:36 PM, Felipe Balbi ba...@ti.com wrote: On Tue, May 28, 2013 at 09:21:01AM +0200, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com 'ick' was changed to 'hsotgusb_ick' 'fck' was changed to 'hsotgusb_fck' Signed-off-by: Jan Luebbe j...@pengutronix.de Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com NAK. Fix your clock data. Do you mean here arch/arm/mach-omap2/cclock3xxx_data.c? Yegor -- 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: Chipidea usb otg support for IMX/MXS (device functionality)
Hi, On Wed, May 29, 2013 at 08:07:55AM +, Chen Peter-B29397 wrote: Indeed, I've been using the patchset Add tested id switch and vbus connect detect support for Chipidea from Peter for quite some time on top of 3.9 and it works like a charm for the gadget mode on an MX28 platform. BTW, Peter, I've seen that these patches are still not merged in 3.10, is there a reason for that? do you plan on sending a version rebased on top of 3.10 some time in the future? I tried to do the rebasing myself, but the chipidea driver seems to have changed quite heavily, which makes the process quite difficult when you don't know what you're doing :) we already have Peter's patches on v3.10-rc3 [1]. I can spend few bandwidth on upstream work recently, I may have more bandwidth after June 15th. Currently, we still have no conclusion for chipidea core driver's coming work, like Device tree support, how to identify if the controller is OTG supported. Yes, the next important step is getting the of propertys dr_mode and phy_type properly used in the chipidea core. [1] http://git.pengutronix.de/?p=mgr/linux.git;a=summary - v3.10/topic/usb-peterchen Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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] usb: musb: fix clock naming
On Tue, 2013-05-28 at 20:36 +0300, Felipe Balbi wrote: On Tue, May 28, 2013 at 09:21:01AM +0200, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com 'ick' was changed to 'hsotgusb_ick' 'fck' was changed to 'hsotgusb_fck' Signed-off-by: Jan Luebbe j...@pengutronix.de Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com NAK. Fix your clock data. Yegor, I'm not sure how my signed-off-by got here. It seems that you picked the patch up from this thread: http://marc.info/?l=linux-omapm=134390141101734 Note that my mail contains no signed-off-by and the change is described as a work around. Regards, Jan -- 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 USB file storage gadget with new UDC
Hi, Is it possible to contribute the code to Linux community? Yes. But first you should test it with other gadget drivers, not just g_file_storage. Ok. What other gadget driver can i test with UDC driver? Is it the mass storage driver (mass_storage.c)? Has the g_file_storage passed the USB 2.0 Command Verifier test? On the other hand, i run the USB 2.0 command verifier to test the gadget, the gadget crashes at BOS descriptor test. I think the gadget is not able to handle BOS descriptor, is the gadget driver setup function returning negative error code for BOS descriptor? The crash dump you attached contained this line: PC is at kagen2_irq+0x290/0x3bc [kagen2_udc] This means the crash occurred inside the UDC driver, not the gadget driver. Yes, the problem was solved just now. Thanks, victor -- 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/5] USB: PHY: Improve PHY selection logic
Hi, Improve Kconfig so that the relevant PHY driver can be explicitely selected by the controller driver instead of relying on the user to do so. Detailed description in patch 1. cheers, -roger Roger Quadros (5): USB: PHY: Make PHY driver selection possible by controller drivers USB: ehci-omap: select NOP_USB_XCEIV PHY driver USB: ehci-msm: USB_EHCI_MSM need not depend on USB_PHY USB: lpc32xx: USB_LPC32XX need not depend on USB_PHY USB: OMAP: USB_OMAP need not depend USB_PHY drivers/usb/Makefile |3 +-- drivers/usb/gadget/Kconfig |2 -- drivers/usb/host/Kconfig |5 + drivers/usb/phy/Kconfig| 31 +-- 4 files changed, 23 insertions(+), 18 deletions(-) -- 1.7.4.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
[PATCH 2/5] USB: ehci-omap: select NOP_USB_XCEIV PHY driver
ehci-omap needs NOP_USB_XCEIV PHY driver to function properly, so select it. As the USB PHY drivers no longer depend on USB_PHY, it is safe to select the PHY drivers. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/host/Kconfig |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 344d5e2..5561b47 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -150,13 +150,11 @@ config USB_EHCI_MXC config USB_EHCI_HCD_OMAP tristate EHCI support for OMAP3 and later chips depends on ARCH_OMAP + select NOP_USB_XCEIV default y ---help--- Enables support for the on-chip EHCI controller on OMAP3 and later chips. - If your system uses a PHY on the USB port, you will need to - enable USB_PHY and the appropriate PHY driver as well. Most - boards need the NOP_USB_XCEIV PHY driver. config USB_EHCI_HCD_ORION tristate Support for Marvell EBU on-chip EHCI USB controller -- 1.7.4.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
[PATCH 3/5] USB: ehci-msm: USB_EHCI_MSM need not depend on USB_PHY
As the USB PHY drivers no longer depend on USB_PHY but select it if needed, the controller drivers need not depend on USB_PHY. They can safely select the necessary PHY driver i.e. USB_MSM_OTG in this case. Signed-off-by: Roger Quadros rog...@ti.com CC: Pavankumar Kondeti pkond...@codeaurora.org --- drivers/usb/host/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 5561b47..48e1b70 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -186,7 +186,6 @@ config USB_EHCI_HCD_AT91 config USB_EHCI_MSM tristate Support for Qualcomm QSD/MSM on-chip EHCI USB controller depends on ARCH_MSM - depends on USB_PHY select USB_EHCI_ROOT_HUB_TT select USB_MSM_OTG ---help--- -- 1.7.4.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
[PATCH 4/5] USB: lpc32xx: USB_LPC32XX need not depend on USB_PHY
As the USB PHY drivers no longer depend on USB_PHY but select it if needed, the controller drivers need not depend on USB_PHY. They can safely select the necessary PHY driver i.e. USB_ISP1301 in this case. Signed-off-by: Roger Quadros rog...@ti.com CC: Roland Stigge sti...@antcom.de --- drivers/usb/gadget/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index f41aa0d..2b98bce 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -144,7 +144,6 @@ config USB_AT91 config USB_LPC32XX tristate LPC32XX USB Peripheral Controller depends on ARCH_LPC32XX - depends on USB_PHY select USB_ISP1301 help This option selects the USB device controller in the LPC32xx SoC. -- 1.7.4.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
[PATCH 5/5] USB: OMAP: USB_OMAP need not depend USB_PHY
As the USB PHY drivers no longer depend on USB_PHY but select it if needed, the controller drivers need not depend on USB_PHY. They can safely select the necessary PHY driver i.e. ISP1301_OMAP in this case. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/gadget/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 2b98bce..86d5d80 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -194,7 +194,6 @@ config USB_FUSB300 config USB_OMAP tristate OMAP USB Device Controller depends on ARCH_OMAP1 - depends on USB_PHY select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG help Many Texas Instruments OMAP processors have flexible full -- 1.7.4.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 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Tue, May 28, 2013 at 6:27 PM, Felipe Balbi ba...@ti.com wrote: On Wed, May 15, 2013 at 07:18:01PM +0200, Linus Walleij wrote: I can't merge any of this without Felipes ACKs in any case. Do you want to take this yourself ? I haven't fully read the series yet, but seems like this depends on the rest of the series. If you want to take it, let me know I can ack the patches as soon as I'm done reviewing. Yes please. They are dependent on a stash of patches that that has recently landed in the ARM SoC tree, so currently they need to follow those through the same tree, which is where I funnel all the ux500 stuff. Yours, Linus Walleij -- 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 0/5] USB: PHY: Improve PHY selection logic
On Wednesday 29 May 2013 14:43:26 Roger Quadros wrote: Improve Kconfig so that the relevant PHY driver can be explicitely selected by the controller driver instead of relying on the user to do so. Detailed description in patch 1. I think you have to fold patches 3-5 into patch 1, otherwise you get a circular dependency between the Kconfig options during bisection. 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: [PATCH 0/5] USB: PHY: Improve PHY selection logic
On 05/29/2013 02:59 PM, Arnd Bergmann wrote: On Wednesday 29 May 2013 14:43:26 Roger Quadros wrote: Improve Kconfig so that the relevant PHY driver can be explicitely selected by the controller driver instead of relying on the user to do so. Detailed description in patch 1. I think you have to fold patches 3-5 into patch 1, otherwise you get a circular dependency between the Kconfig options during bisection. You are right. I'll fix that in v2. I'll first wait for more comments on the overall approach. cheers, -roger -- 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: Chipidea usb otg support for IMX/MXS (device functionality)
Hi Michael, On Wed, May 29, 2013 at 12:13:32PM +0200, Michael Grzeschik wrote: Hi, On Wed, May 29, 2013 at 08:07:55AM +, Chen Peter-B29397 wrote: Indeed, I've been using the patchset Add tested id switch and vbus connect detect support for Chipidea from Peter for quite some time on top of 3.9 and it works like a charm for the gadget mode on an MX28 platform. BTW, Peter, I've seen that these patches are still not merged in 3.10, is there a reason for that? do you plan on sending a version rebased on top of 3.10 some time in the future? I tried to do the rebasing myself, but the chipidea driver seems to have changed quite heavily, which makes the process quite difficult when you don't know what you're doing :) we already have Peter's patches on v3.10-rc3 [1]. Wow, great, thanks! I can spend few bandwidth on upstream work recently, I may have more bandwidth after June 15th. Currently, we still have no conclusion for chipidea core driver's coming work, like Device tree support, how to identify if the controller is OTG supported. Yes, the next important step is getting the of propertys dr_mode and phy_type properly used in the chipidea core. I totally admit lacking some context here, but how does the device tree move prevent from merging these patches? Do they have any shortcomings? I've been using them with DT for quite some time and it seems to be working pretty well if you ask me... Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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: Chipidea usb otg support for IMX/MXS (device functionality)
On Wed, May 29, 2013 at 02:19:16PM +0200, maxime.rip...@free-electrons.com wrote: Hi Michael, On Wed, May 29, 2013 at 12:13:32PM +0200, Michael Grzeschik wrote: Hi, On Wed, May 29, 2013 at 08:07:55AM +, Chen Peter-B29397 wrote: Indeed, I've been using the patchset Add tested id switch and vbus connect detect support for Chipidea from Peter for quite some time on top of 3.9 and it works like a charm for the gadget mode on an MX28 platform. BTW, Peter, I've seen that these patches are still not merged in 3.10, is there a reason for that? do you plan on sending a version rebased on top of 3.10 some time in the future? I tried to do the rebasing myself, but the chipidea driver seems to have changed quite heavily, which makes the process quite difficult when you don't know what you're doing :) we already have Peter's patches on v3.10-rc3 [1]. Wow, great, thanks! I can spend few bandwidth on upstream work recently, I may have more bandwidth after June 15th. Currently, we still have no conclusion for chipidea core driver's coming work, like Device tree support, how to identify if the controller is OTG supported. Yes, the next important step is getting the of propertys dr_mode and phy_type properly used in the chipidea core. I totally admit lacking some context here, but how does the device tree move prevent from merging these patches? Do they have any shortcomings? I've been using them with DT for quite some time and it seems to be working pretty well if you ask me... Peters patches need some more care, as they are not cleanly sperated. One patch e.g. adds an delayed worker to handle the otg events. Another one above that patch is removing the worker afterwards. -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v1 0/3] babble error workaround for am335x platform
During the babble condition on usb bus, the musb controller removes the session and stops host mode functionality. All the devices connected to root port will be disconnected due to this babble event. As part of recovery of babble bus condition, restarting the controller is needed as all devices got disconnected. Just setting the session bit would not be sufficient as the configured endpoint fifo register getting changed during this condition as confirmed by HW/IP owner of musb controller. This patch set series adds the support to handle the babble error recovery mechanism, this can be extended to other musb platforms. This patch has been verified on tree [1] and tested on am335x platforms. [1] git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git Ravi Babu (3): usb: musb: core: added musb_restart() API to handle babble condition usb: musb: core: added babble recovery func-ptr to musb-ops usb: musb: dsps: handle babble condition for dsps platform drivers/usb/musb/musb_core.c | 30 ++ drivers/usb/musb/musb_core.h |8 drivers/usb/musb/musb_dsps.c | 34 +- 3 files changed, 71 insertions(+), 1 deletions(-) -- 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 v1 2/3] usb: musb: core: added babble recovery func-ptr to musb-ops
Adding babble_recovery operation as part of musb-ops, used
to recover from babble condition during babble interrupt.
Signed-off-by: Ravi Babu ravib...@ti.com
---
drivers/usb/musb/musb_core.c |6 ++
drivers/usb/musb/musb_core.h |7 +++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index ab6fa39..411c29d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -857,6 +857,12 @@ b_host:
}
}
+ /* handle babble condition */
+ if (int_usb MUSB_INTR_BABBLE) {
+ pr_info(babble: restarting the musb controller..);
+ musb_babble_recovery(musb);
+ }
+
#if 0
/* REVISIT ... this would be for multiplexing periodic endpoints, or
* supporting transfer phasing to prevent exceeding ISO bandwidth
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index f96e899..bf37dc9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -213,6 +213,8 @@ struct musb_platform_ops {
int (*adjust_channel_params)(struct dma_channel *channel,
u16 packet_sz, u8 *mode,
dma_addr_t *dma_addr, u32 *len);
+
+ void(*babble_recovery)(struct musb *musb);
};
/*
@@ -590,4 +592,9 @@ static inline int musb_platform_exit(struct musb *musb)
return musb-ops-exit(musb);
}
+static inline void musb_babble_recovery(struct musb *musb)
+{
+ if (musb-ops-babble_recovery)
+ musb-ops-babble_recovery(musb);
+}
#endif /* __MUSB_CORE_H__ */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 1/3] usb: musb: core: added musb_restart() API to handle babble condition
Added musb_restart() API, used for restart of the musb controller by
the glue layer, when there is babble condition occured on the bus.
During babble condition, the musb controller will remove the session
and no longer in host-mode. As part of recovery this API can be used
to restart the musb controller.
Signed-off-by: Ravi Babu ravib...@ti.com
---
drivers/usb/musb/musb_core.c | 24
drivers/usb/musb/musb_core.h |1 +
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..ab6fa39 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1373,6 +1373,30 @@ static int ep_config_from_hw(struct musb *musb)
return 0;
}
+/*
+ * musb_restart - restarts musb controller
+ * @param musb the controller
+ */
+int musb_restart(struct musb *musb)
+{
+ int status = 0;
+
+ /* during babble condition the musb controller removes the
+* session bit and the fifo table initialized value get changed
+*/
+ if (musb-dyn_fifo)
+ status = ep_config_from_table(musb);
+ else
+ status = ep_config_from_hw(musb);
+
+ /* starts session */
+ if (!status)
+ musb_start(musb);
+
+ return status;
+}
+EXPORT_SYMBOL_GPL(musb_restart);
+
enum { MUSB_CONTROLLER_MHDRC, MUSB_CONTROLLER_HDRC, };
/* Initialize MUSB (M)HDRC part of the USB hardware subsystem;
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..f96e899 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -522,6 +522,7 @@ extern const char musb_driver_name[];
extern void musb_start(struct musb *musb);
extern void musb_stop(struct musb *musb);
+extern int musb_restart(struct musb *musb);
extern void musb_write_fifo(struct musb_hw_ep *ep, u16 len, const u8 *src);
extern void musb_read_fifo(struct musb_hw_ep *ep, u16 len, u8 *dst);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 3/3] usb: musb: dsps: handle babble condition for dsps platform
Adding babble recovery mechanism for dsps platform and as part
of babble recovery the controller will be restarted.
Signed-off-by: Ravi Babu ravib...@ti.com
---
drivers/usb/musb/musb_dsps.c | 34 +-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 958c6b6..efe95e1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -294,9 +294,17 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
* value but DEVCTL.BDEVICE is invalid without DEVCTL.SESSION set.
* Also, DRVVBUS pulses for SRP (but not at 5V) ...
*/
- if (is_host_active(musb) usbintr MUSB_INTR_BABBLE)
+ if (is_host_active(musb) usbintr MUSB_INTR_BABBLE) {
pr_info(CAUTION: musb: Babble Interrupt Occurred\n);
+ /* during babble condition the musb controller removes
+* session (or stops) and no longer in host mode. Hence
+* all the devices connected to root hub gets disconnected
+*/
+ musb-int_usb = MUSB_INTR_BABBLE | MUSB_INTR_DISCONNECT;
+ musb-int_tx = musb-int_rx = 0;
+ }
+
if (usbintr ((1 wrp-drvvbus) wrp-usb_shift)) {
int drvvbus = dsps_readl(reg_base, wrp-status);
void __iomem *mregs = musb-mregs;
@@ -428,6 +436,29 @@ static int dsps_musb_exit(struct musb *musb)
return 0;
}
+static void dsps_musb_restart(struct musb *musb)
+{
+ struct device *dev = musb-controller;
+ struct dsps_glue *glue = dev_get_drvdata(dev-parent);
+ const struct dsps_musb_wrapper *wrp = glue-wrp;
+ void __iomem *reg_base = musb-ctrl_base;
+
+ /* Reset the musb */
+ dsps_writel(reg_base, wrp-control, (1 wrp-reset));
+ udelay(100);
+
+ /* Stop the on-chip PHY and its PLL. */
+ usb_phy_vbus_off(musb-xceiv);
+ udelay(100);
+
+ /* Start the on-chip PHY and its PLL. */
+ usb_phy_vbus_on(musb-xceiv);
+ udelay(100);
+
+ /* reinit the endpoint fifo table and restart musb */
+ musb_restart(musb);
+}
+
static struct musb_platform_ops dsps_ops = {
.init = dsps_musb_init,
.exit = dsps_musb_exit,
@@ -436,6 +467,7 @@ static struct musb_platform_ops dsps_ops = {
.disable= dsps_musb_disable,
.try_idle = dsps_musb_try_idle,
+ .babble_recovery = dsps_musb_restart,
};
static u64 musb_dmamask = DMA_BIT_MASK(32);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [regression] USB: EHCI: changes related to qh_refresh()
Thank you, this patch fixes this issue.
Am 28.05.2013 16:23, schrieb Alan Stern:
On Mon, 27 May 2013, Oleksij Rempel wrote:
Hmmm. Maybe we can narrow this down. What happens if you apply only
parts of the commit?
For example, on top of c97041a, try applying only the hunks that change
ehci-sched.c. If that works, try applying also only the last hunk
affecting ehci-q.c. If that works, try applying also the two previous
hunks.
after ehci-sched.c hank i have this problem again:
+++ b/drivers/usb/host/ehci-sched.c
@@ -792,7 +792,6 @@ static int qh_schedule(struct ehci_hcd *ehci, struct
ehci_qh
unsignedframe; /* 0..(qh-period - 1), or
NO_FRAME */
struct ehci_qh_hw *hw = qh-hw;
- qh_refresh(ehci, qh);
hw-hw_next = EHCI_LIST_END(ehci);
frame = qh-start;
@@ -844,8 +843,6 @@ static int qh_schedule(struct ehci_hcd *ehci, struct
ehci_qh
} else
ehci_dbg (ehci, reused qh %p schedule\n, qh);
- /* stuff into the periodic schedule */
- qh_link_periodic(ehci, qh);
done:
return status;
}
@@ -891,6 +888,12 @@ static int intr_submit (
qh = qh_append_tds(ehci, urb, qtd_list, epnum, urb-ep-hcpriv);
BUG_ON (qh == NULL);
+ /* stuff into the periodic schedule */
+ if (qh-qh_state == QH_STATE_IDLE) {
+ qh_refresh(ehci, qh);
+ qh_link_periodic(ehci, qh);
+ }
+
/* ... update usbfs periodic stats */
ehci_to_hcd(ehci)-self.bandwidth_int_reqs++;
Good grief, I can't believe I forgot to include this material in the
original commit. I really am getting careless...
Anyway, this should fix the problem.
Alan Stern
Index: usb-3.9/drivers/usb/host/ehci-sched.c
===
--- usb-3.9.orig/drivers/usb/host/ehci-sched.c
+++ usb-3.9/drivers/usb/host/ehci-sched.c
@@ -646,6 +646,10 @@ static void end_unlink_intr(struct ehci_
/* reschedule QH iff another request is queued */
if (!list_empty(qh-qtd_list) ehci-rh_state == EHCI_RH_RUNNING) {
rc = qh_schedule(ehci, qh);
+ if (rc == 0) {
+ qh_refresh(ehci, qh);
+ qh_link_periodic(ehci, qh);
+ }
/* An error here likely indicates handshake failure
* or no space left in the schedule. Neither fault
@@ -653,9 +657,10 @@ static void end_unlink_intr(struct ehci_
*
* FIXME kill the now-dysfunctional queued urbs
*/
- if (rc != 0)
+ else {
ehci_err(ehci, can't reschedule qh %p, err %d\n,
qh, rc);
+ }
}
/* maybe turn off periodic schedule */
--
Regards,
Oleksij
--
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 4/5] USB: lpc32xx: USB_LPC32XX need not depend on USB_PHY
On 05/29/2013 01:43 PM, Roger Quadros wrote: As the USB PHY drivers no longer depend on USB_PHY but select it if needed, the controller drivers need not depend on USB_PHY. They can safely select the necessary PHY driver i.e. USB_ISP1301 in this case. Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Roland Stigge sti...@antcom.de Tested-by: Roland Stigge sti...@antcom.de Thanks! CC: Roland Stigge sti...@antcom.de --- drivers/usb/gadget/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index f41aa0d..2b98bce 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -144,7 +144,6 @@ config USB_AT91 config USB_LPC32XX tristate LPC32XX USB Peripheral Controller depends on ARCH_LPC32XX - depends on USB_PHY select USB_ISP1301 help This option selects the USB device controller in the LPC32xx SoC. -- 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] usb: xhci: Disable runtime PM suspend for quirky controllers.
On Tue, 28 May 2013, Julius Werner wrote: The policy we want to achieve is to disable runtime PM iff there is a device connected that doesn't have persist_enabled or a reset_resume() handler and whose parent/root hub resets on resume, right? So couldn't Probably just root hub, not parent. A non-root hub that resets upon resume wouldn't be a good idea. Also, we know in advance that the hub driver _does_ have a reset-resume handler. we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing) generic USB_QUIRK_RESET_RESUME on the root hub instead? Then we could handle all of this in the USB core (during device initialization and when changing persist_enabled through sysfs) by just checking for udev-reset_resume on all parent hubs of the device in question (and use pm_runtime_get/put() on said device to prevent its parents from suspending as appropriate). This sounds too intricate to me. You might want to prevent resets even if the device does support reset-resume, because they consume time. Or you might not care about resets even if persist isn't enabled (consider a USB mouse, for example). I agree that setting the RESET_RESUME quirk on the root hub is a good way to represent the situation. And perhaps the kernel could implement a useful default policy -- but userspace should ultimately remain in control. 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: USB3 SSD/HD device file disappears after eject
[...] sd 8:0:0:0: [sdb] Synchronizing SCSI cache sd 8:0:0:0: Device offlined - not ready after error recovery Unplugging and replugging the device does not result in the reappearance of the /dev/sdb device file like it does with my other external drives. The only way to bring the /dev/sdb device file back is to 'modprobe -r xhci_hcd modprobe xhci_hcd'. [...] I'm not sure where the problem is exactly but I think it is really a problem with the power down of some USB hardware in the chain. I am wondering why this still exists on your quite new hardware. Do you think it must be a problem with power down of the USB3 SSD since this doesn't happen with a USB3 HD I have? I see this here on my own (a few years old) laptop with experimenting some power control settings. I think your USB port got power switched off and so can't detect that you have re-plugged a new device. So my idea is, with reloading the kernel module the power is switched on again. Maybe there should be a config option in userspace to disable powerdown and only unmount filesystems if it is not possible to detect powerdown support of hardware?! I'm not sure I follow. Why only unmount filesystems if it isn't possible to detect powerdown support of hardware (is that the port or the drive)? I noticed this in linux-3.10-rc2 for the first time but I think it is always enabled on previous kernels and this option only allows it to be disabled: CONFIG_USB_DEFAULT_PERSIST: Say N here if you don't want USB power session persistance enabled by default. If you say N it will make suspended USB devices that lose power get reenumerated as if they had been unplugged, causing any mounted filesystems to be lost. The persist feature can still be enabled for individual devices through the power/persist sysfs node. See Documentation/usb/persist.txt for more info. Should I file a kernel bug? - Grant -- 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] USB: serial: add support Infineon modem USB flashloader driver
If you want to download Infineon modem via USB, this Infineon USB
flashloader driver is required.
Signed-off-by: Wei Shuai cpuw...@gmail.com
---
drivers/usb/serial/Kconfig | 10 ++
drivers/usb/serial/Makefile |1 +
drivers/usb/serial/flashloader.c | 39 ++
3 files changed, 50 insertions(+)
create mode 100644 drivers/usb/serial/flashloader.c
diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 17b7f9a..cccd495 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -693,6 +693,16 @@ config USB_SERIAL_QT2
To compile this driver as a module, choose M here: the
module will be called quatech-serial.
+config USB_SERIAL_FLASHLOADER
+ tristate Infineon Modem Flashloader USB interface driver
+ help
+ Say Y here if you want to download Infineon Modem
+ via USB Flashloader serial driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called flashloader.
+
+
config USB_SERIAL_DEBUG
tristate USB Debugging Device
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index eaf5ca1..0b2ce56 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_USB_SERIAL_VIVOPAY_SERIAL) +=
vivopay-serial.o
obj-$(CONFIG_USB_SERIAL_XSENS_MT) += xsens_mt.o
obj-$(CONFIG_USB_SERIAL_ZIO) += zio.o
obj-$(CONFIG_USB_SERIAL_ZTE) += zte_ev.o
+obj-$(CONFIG_USB_SERIAL_FLASHLOADER) += flashloader.o
diff --git a/drivers/usb/serial/flashloader.c b/drivers/usb/serial/flashloader.c
new file mode 100644
index 000..e6f5c10
--- /dev/null
+++ b/drivers/usb/serial/flashloader.c
@@ -0,0 +1,39 @@
+/*
+ * Infineon Flashloader driver
+ *
+ * Copyright (C) 2013 Wei Shuai cpuw...@gmail.com
+ *
+ * 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 linux/kernel.h
+#include linux/init.h
+#include linux/tty.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/usb/serial.h
+#include linux/uaccess.h
+
+static const struct usb_device_id id_table[] = {
+ { USB_DEVICE(0x8087, 0x0716) },
+ { },
+};
+MODULE_DEVICE_TABLE(usb, id_table);
+
+static struct usb_serial_driver flashloader_device = {
+ .driver = {
+ .owner =THIS_MODULE,
+ .name = flashloader,
+ },
+ .id_table = id_table,
+ .num_ports =1,
+};
+
+static struct usb_serial_driver * const serial_drivers[] = {
+ flashloader_device, NULL
+};
+
+module_usb_serial_driver(serial_drivers, id_table);
+MODULE_LICENSE(GPL);
--
1.7.9.5
--
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: USB3 SSD/HD device file disappears after eject
On 29.05.2013 17:01, Grant wrote: [...] I'm not sure I follow. Why only unmount filesystems if it isn't possible to detect powerdown support of hardware (is that the port or the drive)? I noticed this in linux-3.10-rc2 for the first time but I think it is always enabled on previous kernels and this option only allows it to be disabled: CONFIG_USB_DEFAULT_PERSIST: Say N here if you don't want USB power session persistance enabled by default. If you say N it will make suspended USB devices that lose power get reenumerated as if they had been unplugged, causing any mounted filesystems to be lost. The persist feature can still be enabled for individual devices through the power/persist sysfs node. See Documentation/usb/persist.txt for more info. Should I file a kernel bug? Hi again, this sounds also related for me to this... [PATCH] usb: xhci: Disable runtime PM suspend for quirky controllers. 1369419177-23281-1-git-send-email-sha...@chromium.org -- 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: USB3 SSD/HD device file disappears after eject
On Tue, 28 May 2013, Grant wrote: OK good point. In light of this, here's the real problem. Ejecting the SSD results in the Writing data to device desktop notification persisting on the desktop instead of disappearing after a few seconds like it does with my other external drives. The following messages appears in dmesg which does not appear when ejecting my other external drives: sd 8:0:0:0: [sdb] Synchronizing SCSI cache sd 8:0:0:0: Device offlined - not ready after error recovery Unplugging and replugging the device does not result in the reappearance of the /dev/sdb device file like it does with my other external drives. The only way to bring the /dev/sdb device file back is to 'modprobe -r xhci_hcd modprobe xhci_hcd'. I originally wrote a problem report like this but then I convinced myself that the *real* problem was the one I described in my previous message which Greg proved it is not. There are two things you can do to help diagnose this. One is to build a kernel with CONFIG_USB_DEBUG enabled and then post the portion of the dmesg log showing what happens when you eject, unplug, and replug the device. The other is to capture and post a usbmon trace of the same sequence of events. See Documentation/usb/usbmon.txt. 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 USB file storage gadget with new UDC
On Wed, 29 May 2013, victor yeo wrote: Hi, Is it possible to contribute the code to Linux community? Yes. But first you should test it with other gadget drivers, not just g_file_storage. Ok. What other gadget driver can i test with UDC driver? Is it the mass storage driver (mass_storage.c)? That is essentially the same as g_file_storage. But there are lots of others. You should start with g_zero and run the testusb suite. See http://www.linux-usb.org/gadget/ and http://www.linux-usb.org/usbtest/ for more information. Those web pages are pretty old and somewhat out of date, but they still have useful stuff. Has the g_file_storage passed the USB 2.0 Command Verifier test? I think so, but I haven't tested it myself. Of course, the result will vary depending on which UDC driver you test. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: EHCI: fix regression related to qh_refresh()
This patch adds some code that inadvertently got left out of commit
c1fdb68e3d73741630ca16695cf9176c233be7ed (USB: EHCI: changes related
to qh_refresh()). The calls to qh_refresh() and qh_link_periodic()
were taken out of qh_schedule(); therefore it is necessary to call
these routines manually after calling qh_schedule().
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Reported-and-tested-by: Oleksij Rempel li...@rempel-privat.de
---
Of course, this needs to get into 3.10.
[as1687]
drivers/usb/host/ehci-sched.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: usb-3.9/drivers/usb/host/ehci-sched.c
===
--- usb-3.9.orig/drivers/usb/host/ehci-sched.c
+++ usb-3.9/drivers/usb/host/ehci-sched.c
@@ -646,6 +646,10 @@ static void end_unlink_intr(struct ehci_
/* reschedule QH iff another request is queued */
if (!list_empty(qh-qtd_list) ehci-rh_state == EHCI_RH_RUNNING) {
rc = qh_schedule(ehci, qh);
+ if (rc == 0) {
+ qh_refresh(ehci, qh);
+ qh_link_periodic(ehci, qh);
+ }
/* An error here likely indicates handshake failure
* or no space left in the schedule. Neither fault
@@ -653,9 +657,10 @@ static void end_unlink_intr(struct ehci_
*
* FIXME kill the now-dysfunctional queued urbs
*/
- if (rc != 0)
+ else {
ehci_err(ehci, can't reschedule qh %p, err %d\n,
qh, rc);
+ }
}
/* maybe turn off periodic schedule */
--
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/5] USB: ehci-omap: select NOP_USB_XCEIV PHY driver
2013/5/29 Roger Quadros rog...@ti.com: ehci-omap needs NOP_USB_XCEIV PHY driver to function properly, so select it. As the USB PHY drivers no longer depend on USB_PHY, it is safe to select the PHY drivers. Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Adrien Vergé adrienve...@gmail.com Tested-by: Adrien Vergé adrienve...@gmail.com Works well on Pandaboard (OMAP4430). Thank you! -- 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 V8 0/3] USB: OHCI: Start splitting up the driver
On Tue, 28 May 2013, Arnd Bergmann wrote: Seems to basically work now, but I'm getting run-time errors after loading the driver, with patch 1/3 applied: [15916.438452] input: Logitech USB-PS/2 Optical Mouse as /devices/pci:00/:00:12.0/usb3/3-1/3-1:1.0/input/input26 [15916.438584] hid-generic 0003:046D:C050.0017: input,hidraw0: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:12.0-1/input0 [15917.465597] usb 3-3: new full-speed USB device number 3 using ohci-pci [15917.636712] usb 3-3: New USB device found, idVendor=0ccd, idProduct=0077 [15917.636717] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [15917.636721] usb 3-3: Product: USB PnP Sound Device [15917.636724] usb 3-3: Manufacturer: C-Media Electronics Inc. [15917.812827] input: C-Media Electronics Inc. USB PnP Sound Device as /devices/pci:00/:00:12.0/usb3/3-3/3-3:1.3/input/input27 [15917.812919] hid-generic 0003:0CCD:0077.0018: input,hidraw1: USB HID v1.00 Device [C-Media Electronics Inc. USB PnP Sound Device] on usb-:00:12.0-3/input3 [15918.789906] cannot submit urb (err = -18) [15918.790163] cannot submit urb (err = -18) [15918.842095] usb 7-1: new full-speed USB device number 2 using ohci-pci [15919.883135] cannot submit urb (err = -18) [15919.883604] cannot submit urb (err = -18) [15919.883613] cannot submit urb (err = -18) [15919.883616] cannot submit urb (err = -18) [15919.883619] cannot submit urb (err = -18) Those error messages are annoying; they don't use dev_err(), so they don't include the device and driver names. There's no way to know what they refer to. I rather suspect they come from the usbaudio driver. When you ran this test, did you have commit 815fa7b91761 applied? Does the same problem occur without Manjunath's changes? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: FHCI: upgrade the isochronous API
This patch attempts to fix the isochronous API in the fhci-hcd
driver. There are two problems with the current code:
ed-last_iso is used but not set anywhere. The patch changes
its name to ed-next_iso and uses it to store the frame number
of the next available slot in the isochronous stream.
urb-start_frame isn't set when the URB_ISO_ASAP flag is off.
The patch sets it to the next available slot if the stream is
in use, or the current frame otherwise.
This won't give the right behavior when an underrun occurs, but I
don't know enough about the driver to handle that case.
Unfortunately, I don't have any way to test these changes.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Anton Vorontsov avoront...@ru.mvista.com
CC: Li Yang le...@freescale.com
---
[as1684]
drivers/usb/host/fhci-sched.c |8 ++--
drivers/usb/host/fhci.h |2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
Index: usb-3.9/drivers/usb/host/fhci-sched.c
===
--- usb-3.9.orig/drivers/usb/host/fhci-sched.c
+++ usb-3.9/drivers/usb/host/fhci-sched.c
@@ -739,9 +739,13 @@ void fhci_queue_urb(struct fhci_hcd *fhc
}
/* for ISO transfer calculate start frame index */
- if (ed-mode == FHCI_TF_ISO urb-transfer_flags URB_ISO_ASAP)
- urb-start_frame = ed-td_head ? ed-last_iso + 1 :
+ if (ed-mode == FHCI_TF_ISO) {
+ /* Ignore the possibility of underruns */
+ urb-start_frame = ed-td_head ? ed-next_iso :
get_frame_num(fhci);
+ ed-next_iso = (urb-start_frame + urb-interval *
+ urb-number_of_packets) 0x07ff;
+ }
/*
* OHCI handles the DATA toggle itself,we just use the USB
Index: usb-3.9/drivers/usb/host/fhci.h
===
--- usb-3.9.orig/drivers/usb/host/fhci.h
+++ usb-3.9/drivers/usb/host/fhci.h
@@ -338,7 +338,7 @@ struct ed {
/* read only parameters, should be cleared upon initialization */
u8 toggle_carry;/* toggle carry from the last TD submitted */
- u32 last_iso; /* time stamp of last queued ISO transfer */
+ u16 next_iso; /* time stamp of next queued ISO transfer */
struct td *td_head; /* a pointer to the current TD handled */
};
--
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] USB: IMX21: upgrade the isochronous API
This patch attempts to update the imx21-hcd driver to the current
standard for the isochronous API. Firstly, urb-start_frame should
always be set by the driver; it is not an input parameter. Secondly,
the URB_ISO_ASAP flag matters only when an URB is submitted to a
stream that has gotten an underrun. It causes the URB to be scheduled
for the next available slot in the future, rather than the earliest
unused (and expired) slot.
Unfortunately, I don't have any way to test these changes.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Sascha Hauer ker...@pengutronix.de
CC: Martin Fuzzey mfuz...@gmail.com
---
[as1685]
drivers/usb/host/imx21-hcd.c | 43 ++-
1 file changed, 26 insertions(+), 17 deletions(-)
Index: usb-3.9/drivers/usb/host/imx21-hcd.c
===
--- usb-3.9.orig/drivers/usb/host/imx21-hcd.c
+++ usb-3.9/drivers/usb/host/imx21-hcd.c
@@ -809,26 +809,36 @@ static int imx21_hc_urb_enqueue_isoc(str
/* calculate frame */
cur_frame = imx21_hc_get_frame(hcd);
- if (urb-transfer_flags URB_ISO_ASAP) {
- if (list_empty(ep_priv-td_list))
- urb-start_frame = cur_frame + 5;
- else
- urb-start_frame = list_entry(
- ep_priv-td_list.prev,
- struct td, list)-frame + urb-interval;
- }
- urb-start_frame = wrap_frame(urb-start_frame);
- if (frame_after(cur_frame, urb-start_frame)) {
- dev_dbg(imx21-dev,
- enqueue: adjusting iso start %d (cur=%d) asap=%d\n,
- urb-start_frame, cur_frame,
- (urb-transfer_flags URB_ISO_ASAP) != 0);
- urb-start_frame = wrap_frame(cur_frame + 1);
+ i = 0;
+ if (list_empty(ep_priv-td_list)) {
+ urb-start_frame = wrap_frame(cur_frame + 5);
+ } else {
+ urb-start_frame = wrap_frame(list_entry(ep_priv-td_list.prev,
+ struct td, list)-frame + urb-interval);
+
+ if (frame_after(cur_frame, urb-start_frame)) {
+ dev_dbg(imx21-dev,
+ enqueue: adjusting iso start %d (cur=%d)
asap=%d\n,
+ urb-start_frame, cur_frame,
+ (urb-transfer_flags URB_ISO_ASAP) != 0);
+ i = DIV_ROUND_UP(wrap_frame(
+ cur_frame - urb-start_frame),
+ urb-interval);
+ if (urb-transfer_flags URB_ISO_ASAP) {
+ urb-start_frame = wrap_frame(urb-start_frame
+ + i * urb-interval);
+ i = 0;
+ } else if (i = urb-number_of_packets) {
+ ret = -EXDEV;
+ goto alloc_dmem_failed;
+ }
+ }
}
/* set up transfers */
+ urb_priv-isoc_remaining = urb-number_of_packets - i;
td = urb_priv-isoc_td;
- for (i = 0; i urb-number_of_packets; i++, td++) {
+ for (; i urb-number_of_packets; i++, td++) {
unsigned int offset = urb-iso_frame_desc[i].offset;
td-ep = ep;
td-urb = urb;
@@ -840,7 +850,6 @@ static int imx21_hc_urb_enqueue_isoc(str
list_add_tail(td-list, ep_priv-td_list);
}
- urb_priv-isoc_remaining = urb-number_of_packets;
dev_vdbg(imx21-dev, setup %d packets for iso frame %d-%d\n,
urb-number_of_packets, urb-start_frame, td-frame);
--
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] USB: MUSB: upgrade the isochronous API
This patch attempts to fix the isochonour API in the musb host
driver. In particular, the urb-start_frame field should always be
set by the driver; it isn't an input parameter.
The simplest way to accomplish this is to treat all URBs as though the
URB_ISO_ASAP flag was set. This won't give the right behavior when an
underrun occurs, but I don't know enough about the musb driver to
handle that case.
Unfortunately, I have no way to test this change.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
---
[as1686]
drivers/usb/musb/musb_host.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: usb-3.9/drivers/usb/musb/musb_host.c
===
--- usb-3.9.orig/drivers/usb/musb/musb_host.c
+++ usb-3.9/drivers/usb/musb/musb_host.c
@@ -269,8 +269,7 @@ musb_start_urb(struct musb *musb, int is
/* FIXME this doesn't implement that scheduling policy ...
* or handle framecounter wrapping
*/
- if ((urb-transfer_flags URB_ISO_ASAP)
- || (frame = urb-start_frame)) {
+ if (1) {/* Always assume URB_ISO_ASAP */
/* REVISIT the SOF irq handler shouldn't duplicate
* this code; and we don't init urb-start_frame...
*/
--
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 V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
Hi, On Wed, May 29, 2013 at 11:58:01AM +0800, Chao Xie wrote: On Wed, May 29, 2013 at 12:24 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, May 13, 2013 at 10:13:44AM -0400, Alan Stern wrote: On Mon, 13 May 2013, Chao Xie wrote: Originaly, ehci 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 shutdown. It removes the callbacks in platform data, and at same time it removes one block in the way of enabling device tree for ehci driver. I wonder if this is the sort of thing that should be handled in ehci-hcd.c rather than in all the different platform glue drivers. Felipe, what do you think? Are the required actions now sufficiently generic that a single source file can take care of them? Sorry for the delay, was on business trip and now on vacations. Anyway, I agree with you. Our PHY layer should be generic enough that it should be usable by ehci-hcd itself. If we have any missing method, let's add it generically. So what are your idea about making the PHY layer more generic? How ehci-hcd will make use of PHY layer? on probe grab the phy and initialize it. On suspend/resume, suspend/resume the PHY and so on. Whatever you were going to do on your ehci glue, do it on generic ehci-hcd. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/3] palmas usb driver
Hi, On Wed, May 29, 2013 at 11:36:01AM +0530, Kishon Vijay Abraham I wrote: Hi Felipe, On Tuesday 28 May 2013 11:05 PM, Felipe Balbi wrote: On Fri, May 24, 2013 at 08:01:33PM +0530, Kishon Vijay Abraham I wrote: This patch series adds driver for palmas usb which is used to detect attach/detach events of usb device and usb host. [PATCH v5 2/3] extcon: Palmas Extcon Driver which was sent previously is added in this patch series itself. The revision history is added in the patch comments section. A checkpatch warning WARNING: static const char * array should probably be static const char * constis ignored since it introduces a compilation warning. Graeme Gregory (2): drivers: regulator: palmas: add an API to set/clear the switch bit on SMPS10 extcon: Palmas Extcon Driver Kishon Vijay Abraham I (1): usb: dwc3: use extcon fwrk to receive connect/disconnect notification There were some comments to this series, what will happen with it ? Any new versions coming ? I've already sent new versions. Palmas Extcon Driver is already queued in extcon-next. Chanwoo can take this patch in his tree after your ACK. [PATCH v2] usb: dwc3: use extcon fwrk to receive connect/disconnect notification. alright, thanks for the note, here it is: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: cleanup DWC3_DCTL_LSFTRST bit
Hi, On Wed, May 29, 2013 at 02:05:43PM +0800, Huang Rui wrote: Hi Felipe, On Wed, May 29, 2013 at 01:25:59AM +0800, Felipe Balbi wrote: On Tue, May 28, 2013 at 03:42:50PM +0800, Huang Rui wrote: This bit is removed and set as reserved in 2.50a spec. Signed-off-by: Huang Rui ray.hu...@amd.com so ? This driver also works on older versions of the core. What you should do is, perhaps, add a comment saying that this bit shouldn't be used in v2.50a+, then we need to keep an eye for any future users of that bit and make sure that there is proper revision detection around it. Thanks to your reply. I greped codes, in current driver didn't use this bit, and I saw that the bit is marked as reserved in 2.50a spec. I don't confirm this bit should use in v2.50a+, if it will be used or I was wrong, please correct me. I just looked at register mapping, and compared with spec and found this bit is reserved, so I send this patch to remove this define to prevent to confuse. :) it's reserved for 2.50a, what about all the older versions ? What if some older version needs light soft-reset ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: musb: fix clock naming
On Wed, May 29, 2013 at 12:06:52PM +0200, Yegor Yefremov wrote: On Tue, May 28, 2013 at 7:36 PM, Felipe Balbi ba...@ti.com wrote: On Tue, May 28, 2013 at 09:21:01AM +0200, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com 'ick' was changed to 'hsotgusb_ick' 'fck' was changed to 'hsotgusb_fck' Signed-off-by: Jan Luebbe j...@pengutronix.de Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com NAK. Fix your clock data. Do you mean here arch/arm/mach-omap2/cclock3xxx_data.c? yes -- balbi signature.asc Description: Digital signature
Re: [RFC 0/6] xHCI and USB security bug fixes
On Wed, May 29, 2013 at 10:27:50AM +0900, Greg Kroah-Hartman wrote: On Fri, May 24, 2013 at 05:42:52PM -0700, Sarah Sharp wrote: This patchset address some (but not all) of the security issues found with the Klockwork static analysis tool. I have not reviewed these in detail to see if these could be used by attackers, so someone with more security experience may want to look these over. A lot of these changes are just to add checks to functions that you are calling yourself. How can those pointers be not valid when you control what you pass to them? It's purely paranoia. It's entirely possible we'll add new code later that would accidentally trigger these checks. That's especially true of, say, the device speeds, since USB 3.1 (10Gbps) is in the works. Those seems over-eager, and not really needed. Or am I missing somewhere that could change the pointer without the driver knowing it? In all honesty, these patches are the result of a bureaucratic push for code quality. We switched static analysis tools from Coverity to Klockwork, and the QA folks pushed us to fix the issues that Klockwork discovered. If you don't think they're appropriate, let me know, and I'll push back. Sarah Sharp -- 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 4/6] xhci: remove BUG() in xhci_get_endpoint_type()
On Wed, May 29, 2013 at 10:33:26AM +0900, Greg Kroah-Hartman wrote: On Fri, May 24, 2013 at 05:43:01PM -0700, Sarah Sharp wrote: From: Mathias Nyman mathias.ny...@linux.intel.com If the endpoint type is unknown, set it to 0 and fail gracefully instead of causing a kernel panic. How can the endpoint type be unknown? Looking at the USB spec, there's only 2 bits for the endpoint type, so we should never see an unknown endpoint type unless there's a bug in the USB core. The BUG() block could probably just be removed instead, and we'll just ignore Klockwork whining about it. Sarah Sharp -- 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: [GIT PULL] ARM: tegra: DT-related fixes needed by the USB tree
Hi, On Tue, May 28, 2013 at 08:47:04PM +0300, Felipe Balbi wrote: On Tue, May 28, 2013 at 11:15:25AM -0600, Stephen Warren wrote: On 05/17/2013 04:50 PM, Stephen Warren wrote: Felipe, (and Alan, Greg), These are the changes from the Tegra tree that need to be merged before the Tegra USB driver patches 4-8 from Venu can be applied. Recall that we had previously agreed on this approach for v3.9, but Venu's patches didn't end up being ready until now, unfortunately. I note that Venu's patches affect both the Tegra USB and PHY drivers. Felipe, do you know when you plan to pull this into the USB tree, and apply Venu's patches? Thanks. got 35 commits testing right now. This pull is in my list for tomorrow. sorry for the delay, have been on a trip for the last 3 weeks and now I'm catching up with emails during my vacations (next 2 weeks). the tag is not pushed to where you pointed me to. Please make sure to git push it. $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tag tegra-for-3.11-deps-for-usb fatal: Couldn't find remote ref refs/tags/tegra-for-3.11-deps-for-usb -- balbi signature.asc Description: Digital signature
Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote: For all ux500 based platforms the maximum number of end-points are used. Move this knowledge into the driver so we can relinquish the burden from platform data. This also removes quite a bit of complexity from the driver and will aid us when we come to enable the driver for Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org for drivers/usb/musb Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [GIT PULL] ARM: tegra: DT-related fixes needed by the USB tree
On 05/29/2013 11:55 AM, Felipe Balbi wrote: Hi, On Tue, May 28, 2013 at 08:47:04PM +0300, Felipe Balbi wrote: On Tue, May 28, 2013 at 11:15:25AM -0600, Stephen Warren wrote: On 05/17/2013 04:50 PM, Stephen Warren wrote: Felipe, (and Alan, Greg), These are the changes from the Tegra tree that need to be merged before the Tegra USB driver patches 4-8 from Venu can be applied. Recall that we had previously agreed on this approach for v3.9, but Venu's patches didn't end up being ready until now, unfortunately. I note that Venu's patches affect both the Tegra USB and PHY drivers. Felipe, do you know when you plan to pull this into the USB tree, and apply Venu's patches? Thanks. got 35 commits testing right now. This pull is in my list for tomorrow. sorry for the delay, have been on a trip for the last 3 weeks and now I'm catching up with emails during my vacations (next 2 weeks). the tag is not pushed to where you pointed me to. Please make sure to git push it. $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tag tegra-for-3.11-deps-for-usb fatal: Couldn't find remote ref refs/tags/tegra-for-3.11-deps-for-usb Sorry about that. I could have sworn I checked that, but obviously not. Anyway, I've pushed it now, and the command you quoted above works for me, so I think it's replicated out already. -- 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] usb: xhci: Use non-interruptible sleep for XHCI commands
I really wish you had contacted me about this issue before writing code to fix it. Now I don't know the backstory behind this issue, which makes it hard to evaluate whether this fix is correct. On Fri, May 24, 2013 at 06:39:37PM -0700, Julius Werner wrote: The XHCI stack usually uses wait_for_completion_interruptible_timeout() to wait for the completion of an XHCI command, and treats both timeouts and interruptions as errors. This is a bad idea, since these commands are often essential for the correct operation of the USB stack, and their failure can leave devices in a misconfigured and/or unusable state. What causes the devices to be unusable? If a Configure Endpoint command fails, the USB core is supposed to try to put the device back into its original state. Is there a mismatch caused by the command being interrupted, and if so, how can we fix it, rather than allowing the kernel to go into an uninterruptible sleep? While a timeout probably means a real problem that needs to be dealt with, a random signal to the controlling user-space process should not cause such harsh consequences. We should deal with the canceled command gracefully, rather than papering over the issue. This patch changes that behavior to use uninterruptible waits instead. It fixes an easy to reproduce bug that occurs when you kill -9 a process that reads from a UVC camera. The UVC driver's release code tries to set the camera's alternate setting back to 0, but the lingering SIGKILL instantly aborts any Stop Endpoint or Configure Endpoint command sent to the xHC. The code dies halfway through the bandwidth allocation process, leaving the device in an active configuration and preventing future access to it due to the now out-of-sync bandwidth calculation. Obviously the command handling needs to be re-worked so this bandwidth mismatch doesn't happen. What I would like to see instead (but have not had time to implement) is a global command queue manager. It would have a queue of commands, similar to what we do for the TD lists, but only one list per xhci_hcd. The command queue manager would handle cancellation requests, and properly keep track of whether each command completed. Functions submitting commands would all have a unique completion, and wait (interruptibly) on that completion. Commands that are interrupted with a signal should attempt to cancel the command, and wait on the completion to see if their command was canceled or successfully completed. If it was successfully completed, it should return success, rather than -ETIMEOUT. I think that change will fix the case where the bandwidth allocation gets out-of-sync with the USB core, but since you haven't shared the details of how the code handles being interrupted, I can't tell whether this is actually a good solution. Sarah Sharp -- 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 V8 0/3] USB: OHCI: Start splitting up the driver
On Wednesday 29 May 2013 12:21:02 Alan Stern wrote: Those error messages are annoying; they don't use dev_err(), so they don't include the device and driver names. There's no way to know what they refer to. I rather suspect they come from the usbaudio driver. That makes sense. I have a usb audio device, and I don't actually recall getting any sound from my speakers while testing it. I only checked that the mouse was working and assumed that the usb-audio was driven by ehci, but upon closer inspection, they are both on the same OHCI. When you ran this test, did you have commit 815fa7b91761 applied? Yes. Does the same problem occur without Manjunath's changes? No, it was introduced by the first patch, as I found later. 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: [PATCH V8 0/3] USB: OHCI: Start splitting up the driver
On Wed, 29 May 2013, Arnd Bergmann wrote: On Wednesday 29 May 2013 12:21:02 Alan Stern wrote: Those error messages are annoying; they don't use dev_err(), so they don't include the device and driver names. There's no way to know what they refer to. I rather suspect they come from the usbaudio driver. That makes sense. I have a usb audio device, and I don't actually recall getting any sound from my speakers while testing it. I only checked that the mouse was working and assumed that the usb-audio was driven by ehci, but upon closer inspection, they are both on the same OHCI. When you ran this test, did you have commit 815fa7b91761 applied? Yes. Does the same problem occur without Manjunath's changes? No, it was introduced by the first patch, as I found later. I'll try to replicate your result. I don't have my USB audio device here today, so it will have to wait until tomorrow. 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] usb: xhci: Disable runtime PM suspend for quirky controllers.
On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote: The policy we want to achieve is to disable runtime PM iff there is a device connected that doesn't have persist_enabled or a reset_resume() handler and whose parent/root hub resets on resume, right? Makes sense. However, not all distros may want that policy, so there should be a way to change that policy via sysfs. Some distros may choose to take the power savings over having a particular USB device work, especially in the server market. Don, Oliver, what do you think of this patch: http://marc.info/?l=linux-usbm=136941922715772w=2 Julius is proposing to limit the scope of the patch a bit, but the impact will still be that TI hosts will be active more often than not. So couldn't we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing) generic USB_QUIRK_RESET_RESUME on the root hub instead? Then we could handle all of this in the USB core (during device initialization and when changing persist_enabled through sysfs) by just checking for udev-reset_resume on all parent hubs of the device in question (and use pm_runtime_get/put() on said device to prevent its parents from suspending as appropriate). Alan, what happens if we set USB_QUIRK_RESET_RESUME on the roothub? I don't think that currently translates into the host controller's Reset register getting written, which is what I think Julius is proposing. Sarah Sharp -- 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] xhci: Add BayTrail to list of Intel switchable hosts
On Tue, May 28, 2013 at 10:53:56AM +0300, Heikki Krogerus wrote: Hi Sarah, On Fri, May 24, 2013 at 09:55:25AM -0700, Sarah Sharp wrote: At this point the port switchover quirk is getting unwieldy. I know of at least two more platforms that will need the switchover quirk, and it's silly to keep adding them to the list. Heikki, can you change the code to always try to switchover the ports from EHCI to xHCI if an Intel xHCI host is found, and fail gracefully if there isn't an EHCI host controller on board? I suspect Intel will include the port switchover mechanism until they decide to only include xHCI hosts and no EHCI hosts. In the meantime, we can avoid breaking USB 3.0 new platforms by always attempting to do the switchover. OK, makes sense. I or Mathias will make the patch for you. Great, thanks! Sarah Sharp -- 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] usb: xhci: Disable runtime PM suspend for quirky controllers.
On Wed, 29 May 2013, Sarah Sharp wrote: On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote: The policy we want to achieve is to disable runtime PM iff there is a device connected that doesn't have persist_enabled or a reset_resume() handler and whose parent/root hub resets on resume, right? Makes sense. However, not all distros may want that policy, so there should be a way to change that policy via sysfs. Some distros may choose to take the power savings over having a particular USB device work, especially in the server market. Don, Oliver, what do you think of this patch: http://marc.info/?l=linux-usbm=136941922715772w=2 Julius is proposing to limit the scope of the patch a bit, but the impact will still be that TI hosts will be active more often than not. In many cases, the usual default of allowing the root hub to autosuspend will be acceptable. In cases where it isn't, I think we will have to rely on userspace to tell us. The simplest way is for userspace to forbid autosuspend. That may not be flexible enough, but at this point there doesn't seem to be any way for the kernel to include all the different policies that userspace might want. All we can do is make the information available. There already is a quirks attribute in sysfs, but it's probably not good enough for this. The contents are subject to change if we renumber the QUIRK bits. Maybe something more like the avoid_reset attribute. A problem with registering sysfs attributes from within xhci-hcd is that they won't become visible until some time after the device is registered. If a udev script runs too quickly, it won't see the attribute. So couldn't we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing) generic USB_QUIRK_RESET_RESUME on the root hub instead? Then we could handle all of this in the USB core (during device initialization and when changing persist_enabled through sysfs) by just checking for udev-reset_resume on all parent hubs of the device in question (and use pm_runtime_get/put() on said device to prevent its parents from suspending as appropriate). Alan, what happens if we set USB_QUIRK_RESET_RESUME on the roothub? I don't think that currently translates into the host controller's Reset register getting written, which is what I think Julius is proposing. Hmmm. Now that I look more closely, setting the RESET_RESUME quirk on the root hub would prevent it from ever going into runtime suspend, which is not what we are after. (The quirk disables autosuspend for devices whose drivers don't support reset-resume or require remote wakeup.) Oh, well. 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] usb: xhci: Disable runtime PM suspend for quirky controllers.
On Wed, May 29, 2013 at 12:38:28PM -0700, Sarah Sharp wrote: On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote: The policy we want to achieve is to disable runtime PM iff there is a device connected that doesn't have persist_enabled or a reset_resume() handler and whose parent/root hub resets on resume, right? Makes sense. However, not all distros may want that policy, so there should be a way to change that policy via sysfs. Some distros may choose to take the power savings over having a particular USB device work, especially in the server market. Don, Oliver, what do you think of this patch: http://marc.info/?l=linux-usbm=136941922715772w=2 That is limited only to certain controllers right? RHEL6 doesn't support runtime suspend, so we don't hear to many complaints. Most of our server customers don't have much plugged into USB, so I don't expect much problems there. Our laptop customers prefer the power savings, but I don't know how many of them have chipsets with XHCI_RESET_ON_RESUME. Julius is proposing to limit the scope of the patch a bit, but the impact will still be that TI hosts will be active more often than not. Hmm, for some reason I don't see TI having the XHCI_RESET_ON_RESUME quirk set, just VIA and ETRON. Neither of which seem to be normally shipped with servers. Cheers, Don -- 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] usb: xhci: Use non-interruptible sleep for XHCI commands
On Wed, May 29, 2013 at 11:06 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: I really wish you had contacted me about this issue before writing code to fix it. Now I don't know the backstory behind this issue, which makes it hard to evaluate whether this fix is correct. No worries... this was a very trivial patch and didn't take long. I won't mind if we settle on a different solution here eventually (even though I think this is the way that makes sense). The issue is very easy to reproduce: just read of a UVC camera (I use Python with import cv2; dev = cv2.VideoCapture(0); dev.read()) and kill -9 the process. However, you will have to pull in my other patch first (usb: xhci: Fix Command Ring Stopped Event handling), or you may run into a follow-up problem with cancelled commands that kills your whole HCD. On Fri, May 24, 2013 at 06:39:37PM -0700, Julius Werner wrote: The XHCI stack usually uses wait_for_completion_interruptible_timeout() to wait for the completion of an XHCI command, and treats both timeouts and interruptions as errors. This is a bad idea, since these commands are often essential for the correct operation of the USB stack, and their failure can leave devices in a misconfigured and/or unusable state. What causes the devices to be unusable? If a Configure Endpoint command fails, the USB core is supposed to try to put the device back into its original state. Is there a mismatch caused by the command being interrupted, and if so, how can we fix it, rather than allowing the kernel to go into an uninterruptible sleep? The problem is that this happens while the USB core is already trying to put the device back into its default/inactive state: the process gets killed, its /dev/video0 file descriptor gets closed, the uvc_v4l2_release() handler runs and eventually calls usb_set_interface() to return the device to alternate setting 0 (back from the active alternate setting that it was in while transmitting video). But that alternate setting change requires an XHCI command, which gets immediately cancelled because the SIGKILL signal keeps lingering on the process until it is dead. (To be honest I am not quite sure why the device stays unusable after that... I just get bandwidth exceeded errors when I try to read it again from a new process. Maybe there is another error in the bandwidth management code there, but the problem remains that the UVC driver should be allowed to correctly return the device to its default state even during a SIGKILL.) The other thing to note is that we already use uninterruptible sleeps in many other places -- the USB core does it all the time: most prominently in usb_start_wait_urb(), which is used for device communication (SET_ADDRESS, SET_CONFIGURATION, etc.) during enumeration (presumably to avoid similar problems as this patch). This function is even used for the actual SET_INTERFACE message that is sent to the device when changing alternate settings... so does it make sense to make the (usually very fast and reliable, unless the hardware is completely broken) communication with the xHC interruptible, when for the same operation the much more unreliable communication with the device is not? This patch changes that behavior to use uninterruptible waits instead. It fixes an easy to reproduce bug that occurs when you kill -9 a process that reads from a UVC camera. The UVC driver's release code tries to set the camera's alternate setting back to 0, but the lingering SIGKILL instantly aborts any Stop Endpoint or Configure Endpoint command sent to the xHC. The code dies halfway through the bandwidth allocation process, leaving the device in an active configuration and preventing future access to it due to the now out-of-sync bandwidth calculation. Obviously the command handling needs to be re-worked so this bandwidth mismatch doesn't happen. What I would like to see instead (but have not had time to implement) is a global command queue manager. It would have a queue of commands, similar to what we do for the TD lists, but only one list per xhci_hcd. The command queue manager would handle cancellation requests, and properly keep track of whether each command completed. Functions submitting commands would all have a unique completion, and wait (interruptibly) on that completion. Commands that are interrupted with a signal should attempt to cancel the command, and wait on the completion to see if their command was canceled or successfully completed. If it was successfully completed, it should return success, rather than -ETIMEOUT. I think that change will fix the case where the bandwidth allocation gets out-of-sync with the USB core, but since you haven't shared the details of how the code handles being interrupted, I can't tell whether this is actually a good solution. This sounds like a good idea in general, but I don't think it will fix this problem. The issue is not that command cancellation doesn't work (at
[PATCH] usb: gadget: r8a66597-udc: do not unlock unheld spinlock in r8a66597_sudmac_irq()
r8a66597_irq() processes sudmac part (r8a66597_sudmac_irq()) before locking r8a66597-lock. But transfer_complete(), that is called inside (r8a66597_sudmac_irq()-sudmac_finish()-transfer_complete()), expects r8a66597-lock is locked. As a result unheld spinlock can be unlocked. The patch just moves locking before calling r8a66597_sudmac_irq(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru --- drivers/usb/gadget/r8a66597-udc.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/r8a66597-udc.c b/drivers/usb/gadget/r8a66597-udc.c index 7ff7d9c..2dd213c 100644 --- a/drivers/usb/gadget/r8a66597-udc.c +++ b/drivers/usb/gadget/r8a66597-udc.c @@ -1469,11 +1469,11 @@ static irqreturn_t r8a66597_irq(int irq, void *_r8a66597) u16 savepipe; u16 mask0; + spin_lock(r8a66597-lock); + if (r8a66597_is_sudmac(r8a66597)) r8a66597_sudmac_irq(r8a66597); - spin_lock(r8a66597-lock); - intsts0 = r8a66597_read(r8a66597, INTSTS0); intenb0 = r8a66597_read(r8a66597, INTENB0); -- 1.7.9.5 -- 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/2] USB: xhci: rename ambiguous named XHCI_NEC_HOST to XHCI_NEC_SHOW_FW
Current Renesas Electronics XHCI hosts (which were formerly NEC)
do support the same vendor command to show the firmware. Rename the
ambigious named define XHCI_NEC_HOST to XHCI_NEC_SHOW_FW because it's
only used to display the firmware version. Besides that, change the
output ... NEC firmware version x.y to ... firmware version x.y
to not confuse owners of Renesas USB hosts.
(so only cosmetic, no functional changes)
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-ring.c | 6 +++---
drivers/usb/host/xhci.c | 4 ++--
drivers/usb/host/xhci.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 1a30c38..f47d3d2 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -79,7 +79,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
}
if (pdev-vendor == PCI_VENDOR_ID_NEC)
- xhci-quirks |= XHCI_NEC_HOST;
+ xhci-quirks |= XHCI_NEC_SHOW_FW;
if (pdev-vendor == PCI_VENDOR_ID_AMD xhci-hci_version == 0x96)
xhci-quirks |= XHCI_AMD_0x96_HOST;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1969c00..761d566 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1489,11 +1489,11 @@ bandwidth_change:
for disabled slot %u\n, slot_id);
break;
case TRB_TYPE(TRB_NEC_GET_FW):
- if (!(xhci-quirks XHCI_NEC_HOST)) {
+ if (!(xhci-quirks XHCI_NEC_SHOW_FW)) {
xhci-error_bitmask |= 1 6;
break;
}
- xhci_dbg(xhci, NEC firmware version %2x.%02x\n,
+ xhci_dbg(xhci, firmware version %2x.%02x\n,
NEC_FW_MAJOR(le32_to_cpu(event-status)),
NEC_FW_MINOR(le32_to_cpu(event-status)));
break;
@@ -1512,7 +1512,7 @@ static void handle_vendor_event(struct xhci_hcd *xhci,
trb_type = TRB_FIELD_TO_TYPE(le32_to_cpu(event-generic.field[3]));
xhci_dbg(xhci, Vendor specific event TRB type = %u\n, trb_type);
- if (trb_type == TRB_NEC_CMD_COMP (xhci-quirks XHCI_NEC_HOST))
+ if (trb_type == TRB_NEC_CMD_COMP (xhci-quirks XHCI_NEC_SHOW_FW))
handle_cmd_completion(xhci, event-event_cmd);
}
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b4aa79d..b961e9a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -588,7 +588,7 @@ static int xhci_run_finished(struct xhci_hcd *xhci)
xhci-shared_hcd-state = HC_STATE_RUNNING;
xhci-cmd_ring_state = CMD_RING_STATE_RUNNING;
- if (xhci-quirks XHCI_NEC_HOST)
+ if (xhci-quirks XHCI_NEC_SHOW_FW)
xhci_ring_cmd_db(xhci);
xhci_dbg(xhci, Finished xhci_run for USB3 roothub\n);
@@ -673,7 +673,7 @@ int xhci_run(struct usb_hcd *hcd)
xhci-ir_set-irq_pending);
xhci_print_ir_set(xhci, 0);
- if (xhci-quirks XHCI_NEC_HOST)
+ if (xhci-quirks XHCI_NEC_SHOW_FW)
xhci_queue_vendor_command(xhci, 0, 0, 0,
TRB_TYPE(TRB_NEC_GET_FW));
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 29c978e..e483f12 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1493,7 +1493,7 @@ struct xhci_hcd {
unsigned intquirks;
#defineXHCI_LINK_TRB_QUIRK (1 0)
#define XHCI_RESET_EP_QUIRK(1 1)
-#define XHCI_NEC_HOST (1 2)
+#define XHCI_NEC_SHOW_FW (1 2)
#define XHCI_AMD_PLL_FIX (1 3)
#define XHCI_SPURIOUS_SUCCESS (1 4)
/*
--
1.8.1.5
--
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/2] USB: xhci: show firmware version for Renesas XHCI hosts if debug is enabled
They support the same vendor specific command as former NEC hosts. Signed-off-by: Alexander Holler hol...@ahsoftware.de --- drivers/usb/host/xhci-pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index f47d3d2..9977cee 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -78,7 +78,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) xhci-quirks |= XHCI_TRUST_TX_LENGTH; } - if (pdev-vendor == PCI_VENDOR_ID_NEC) + if (pdev-vendor == PCI_VENDOR_ID_NEC || + pdev-vendor == PCI_VENDOR_ID_RENESAS) xhci-quirks |= XHCI_NEC_SHOW_FW; if (pdev-vendor == PCI_VENDOR_ID_AMD xhci-hci_version == 0x96) -- 1.8.1.5 -- 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 V8 0/3] USB: OHCI: Start splitting up the driver
On Wednesday 29 May 2013, Alan Stern wrote: On Wed, 29 May 2013, Arnd Bergmann wrote: On Wednesday 29 May 2013 12:21:02 Alan Stern wrote: Those error messages are annoying; they don't use dev_err(), so they don't include the device and driver names. There's no way to know what they refer to. I rather suspect they come from the usbaudio driver. That makes sense. I have a usb audio device, and I don't actually recall getting any sound from my speakers while testing it. I only checked that the mouse was working and assumed that the usb-audio was driven by ehci, but upon closer inspection, they are both on the same OHCI. When you ran this test, did you have commit 815fa7b91761 applied? Yes. Does the same problem occur without Manjunath's changes? No, it was introduced by the first patch, as I found later. I'll try to replicate your result. I don't have my USB audio device here today, so it will have to wait until tomorrow. Strange enough, it seems to be working now, on a different base. The kernel I tried last (based on yesterday's linux-next) also had other issues and was very slow, so it may have been something different. 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: [PATCH 1/2] USB: xhci: rename ambiguous named XHCI_NEC_HOST to XHCI_NEC_SHOW_FW
On Wed, May 29, 2013 at 11:14:32PM +0200, Alexander Holler wrote:
Current Renesas Electronics XHCI hosts (which were formerly NEC)
do support the same vendor command to show the firmware. Rename the
ambigious named define XHCI_NEC_HOST to XHCI_NEC_SHOW_FW because it's
only used to display the firmware version. Besides that, change the
output ... NEC firmware version x.y to ... firmware version x.y
to not confuse owners of Renesas USB hosts.
(so only cosmetic, no functional changes)
I'm actually inclined to say you should just rip out the firmware
version code entirely. I haven't needed to use it for years, and if
Renesas changed their vendor command set, I would rather not submit
random commands to the host.
So, can you redo this patch to just rip out XHCI_NEC_HOST and everything
that uses it?
Sarah Sharp
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-ring.c | 6 +++---
drivers/usb/host/xhci.c | 4 ++--
drivers/usb/host/xhci.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 1a30c38..f47d3d2 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -79,7 +79,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
}
if (pdev-vendor == PCI_VENDOR_ID_NEC)
- xhci-quirks |= XHCI_NEC_HOST;
+ xhci-quirks |= XHCI_NEC_SHOW_FW;
if (pdev-vendor == PCI_VENDOR_ID_AMD xhci-hci_version == 0x96)
xhci-quirks |= XHCI_AMD_0x96_HOST;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1969c00..761d566 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1489,11 +1489,11 @@ bandwidth_change:
for disabled slot %u\n, slot_id);
break;
case TRB_TYPE(TRB_NEC_GET_FW):
- if (!(xhci-quirks XHCI_NEC_HOST)) {
+ if (!(xhci-quirks XHCI_NEC_SHOW_FW)) {
xhci-error_bitmask |= 1 6;
break;
}
- xhci_dbg(xhci, NEC firmware version %2x.%02x\n,
+ xhci_dbg(xhci, firmware version %2x.%02x\n,
NEC_FW_MAJOR(le32_to_cpu(event-status)),
NEC_FW_MINOR(le32_to_cpu(event-status)));
break;
@@ -1512,7 +1512,7 @@ static void handle_vendor_event(struct xhci_hcd *xhci,
trb_type = TRB_FIELD_TO_TYPE(le32_to_cpu(event-generic.field[3]));
xhci_dbg(xhci, Vendor specific event TRB type = %u\n, trb_type);
- if (trb_type == TRB_NEC_CMD_COMP (xhci-quirks XHCI_NEC_HOST))
+ if (trb_type == TRB_NEC_CMD_COMP (xhci-quirks XHCI_NEC_SHOW_FW))
handle_cmd_completion(xhci, event-event_cmd);
}
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b4aa79d..b961e9a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -588,7 +588,7 @@ static int xhci_run_finished(struct xhci_hcd *xhci)
xhci-shared_hcd-state = HC_STATE_RUNNING;
xhci-cmd_ring_state = CMD_RING_STATE_RUNNING;
- if (xhci-quirks XHCI_NEC_HOST)
+ if (xhci-quirks XHCI_NEC_SHOW_FW)
xhci_ring_cmd_db(xhci);
xhci_dbg(xhci, Finished xhci_run for USB3 roothub\n);
@@ -673,7 +673,7 @@ int xhci_run(struct usb_hcd *hcd)
xhci-ir_set-irq_pending);
xhci_print_ir_set(xhci, 0);
- if (xhci-quirks XHCI_NEC_HOST)
+ if (xhci-quirks XHCI_NEC_SHOW_FW)
xhci_queue_vendor_command(xhci, 0, 0, 0,
TRB_TYPE(TRB_NEC_GET_FW));
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 29c978e..e483f12 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1493,7 +1493,7 @@ struct xhci_hcd {
unsigned intquirks;
#define XHCI_LINK_TRB_QUIRK (1 0)
#define XHCI_RESET_EP_QUIRK (1 1)
-#define XHCI_NEC_HOST(1 2)
+#define XHCI_NEC_SHOW_FW (1 2)
#define XHCI_AMD_PLL_FIX (1 3)
#define XHCI_SPURIOUS_SUCCESS(1 4)
/*
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb-audio regression 3.8.5-3.9.2
Alan Stern wrote: On Sat, 25 May 2013, Tobias Diedrich wrote: I've recently upgraded my kernel from 3.8.5 to 3.9.2 and ran into an issue with usb-audio: With two different usb-headsets, pulseaudio is now regularily losing the microphone audio stream (which just gets 'stuck', i.e. the level indicator bar in pavucontrol doesn't move anymore, but is not at 0). Every time this happens I get kernel messages like these: May 25 11:05:01 nukunuku kernel: [43611.510661] delay: estimated 221, actual 0 May 25 11:06:02 nukunuku kernel: [43672.086015] delay: estimated 222, actual 1 May 25 11:06:02 nukunuku kernel: [43672.102018] delay: estimated 133, actual 0 May 25 11:07:03 nukunuku kernel: [43733.814401] delay: estimated 133, actual 0 May 25 11:08:02 nukunuku kernel: [43792.636147] delay: estimated 89, actual 0 May 25 11:10:03 nukunuku kernel: [43913.539550] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539610] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539622] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539630] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539637] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539643] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539658] cannot submit urb (err = -18) May 25 11:10:03 nukunuku kernel: [43913.539664] cannot submit urb (err = -18) Now, replugging the headset fixes the issue temporarily until it happens again, but that's a bit annoying if you're in a video call... 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03) 00:10.1 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) usb-audio devices in question: Bus 003 Device 004: ID 041e:0401 Creative Technology, Ltd Bus 004 Device 002: ID 041e:30df Creative Technology, Ltd Bus 004 Device 003: ID 047f:c009 Plantronics, Inc. Please post the contents of /sys/kernel/debug/usb/devices. Still happens on 3.9.4 (although it only happened once there so far, and not (yet?) on the XHCI port, which I previously hadn't compiled in the drivers for (new board)). T: Bus=09 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 P: Vendor=1d6b ProdID=0003 Rev= 3.05 S: Manufacturer=Linux 3.9.4 xhci_hcd S: Product=xHCI Host Controller S: SerialNumber=:00:10.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 3.05 S: Manufacturer=Linux 3.9.4 xhci_hcd S: Product=xHCI Host Controller S: SerialNumber=:00:10.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=08 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=041e ProdID=0401 Rev= 1.33 S: Manufacturer=Creative HS-1200 Headset S: Product=Creative HS-1200 Headset C:* #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio I:* If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio E: Ad=01(O) Atr=09(Isoc) MxPS= 288 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio I: If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio E: Ad=82(I) Atr=05(Isoc) MxPS= 34 Ivl=1ms I:* If#= 3 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=10ms T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 P: Vendor=1d6b ProdID=0003 Rev= 3.05 S: Manufacturer=Linux 3.9.4 xhci_hcd S: Product=xHCI Host Controller S: SerialNumber=:00:10.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00
Re: Misbehaving device
On 05/22/2013 12:27 PM, Alan Stern wrote: On Wed, 22 May 2013, Joe Julian wrote: On 05/21/2013 03:20 PM, Joe Julian wrote: I have about 100 of these creditcard/check scanners that are dropping events. I was able to find some overflows that I assume are probably related to the problem, usb 4-1: ctrl urb status -75 received. Short of asking the vendor to fix their product or compiling a custom kernel, are there any other options? Can the MaxPacketSize or the buffer size be overridden somehow (/sys/bus/usb/devices... maybe)? I have started a dialog with UIC (Uniform Industrial Corp) about a fix, but I'm not very hopeful. Is there anything I can do to work around the overflow? Without knowing more (like where the overflows occur and what data was expected), it is impossible to answer this question. A usbmon trace would help. I spent the day at one of our stores capturing data from a small handful of customer loyalty cards I picked up for this purpose. I was able to capture 2 bad scans. If I'm reading this correctly, there's nothing wrong that could be corrected from the linux side, could you confirm? I think that overflow was a red herring as none occurred during the bad scans. The best example is the last scan of the Qdoba card that ends in I (7th from the bottom). The usbmon capture is at http://joejulian.name/media/uploads/usbcapture.usbmon.gz The expected scan data was successive scans of the following cards: %B6277200522629830^^391200077861?[ %B6277200522629848^^391200017860?S %B6277200522629855^^391200027724?S %B6277200522629863^^391200055339?[ %B6277200522629871^^391200079146?\ %B6010565032591577^QDOBA/VALUELINK^2501000460072408 ?@ %B6010565032591494^QDOBA/VALUELINK^2501000460073301 ?C %B6010565032591700^QDOBA/VALUELINK^2501000460076767 ?L %B6010565032591551^QDOBA/VALUELINK^2501000460073264 ?I %B6010565032591536^QDOBA/VALUELINK^2501000460075630 ?K %B6010565032591528^QDOBA/VALUELINK^2501000460072347 ?F %B6010565032591569^QDOBA/VALUELINK^2501000460075724 ?E %B6010565032591544^QDOBA/VALUELINK^2501000460075630 ?N %B6010565032591502^QDOBA/VALUELINK^2501000460074630 ?M %B6010565032591510^QDOBA/VALUELINK^2501000460074982 ?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
Re: [PATCH] usb: gadget: add Faraday fotg210_udc driver
Hi,
On Wed, May 29, 2013 at 06:31:50PM +, Yuan-Hsin Chen wrote:
Faraday fotg210 udc driver supports only Bulk transfer so far.
fotg210 could be configured as an USB2.0 peripheral.
This driver is tested with mass storage gadget driver on Faraday
EVB a369.
Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com
Run through checkpatch.pl --strict and fix all errors, warnings and all
checks which make sense.
WARNING: please write a paragraph that describes the config symbol fully
#81: FILE: drivers/usb/gadget/Kconfig:196:
+config USB_FOTG210_UDC
CHECK: braces {} should be used on all arms of this statement
#183: FILE: drivers/usb/gadget/fotg210-udc.c:76:
+ if (ep-epnum) {
[...]
+ } else
[...]
WARNING: line over 80 characters
#190: FILE: drivers/usb/gadget/fotg210-udc.c:83:
+static void fotg210_fifo_ep_mapping(struct fotg210_ep *ep, u32 epnum, u32
dir_in)
WARNING: line over 80 characters
#237: FILE: drivers/usb/gadget/fotg210-udc.c:130:
+static void fotg210_set_mps(struct fotg210_ep *ep, u32 epnum, u32 mps, u32
dir_in)
WARNING: line over 80 characters
#241: FILE: drivers/usb/gadget/fotg210-udc.c:134:
+ u32 offset = dir_in ? FOTG210_INEPMPSR(epnum) :
FOTG210_OUTEPMPSR(epnum);
WARNING: line over 80 characters
#349: FILE: drivers/usb/gadget/fotg210-udc.c:242:
+static void fotg210_ep_free_request(struct usb_ep *_ep, struct usb_request
*_req)
WARNING: Avoid CamelCase: DMATFNR_ACC_Fn
#372: FILE: drivers/usb/gadget/fotg210-udc.c:265:
+ value |= DMATFNR_ACC_Fn(ep-epnum - 1);
WARNING: line over 80 characters
#418: FILE: drivers/usb/gadget/fotg210-udc.c:311:
+ value = ioread32(ep-fotg210-reg + FOTG210_FIBCR(ep-epnum -
1));
WARNING: line over 80 characters
#420: FILE: drivers/usb/gadget/fotg210-udc.c:313:
+ iowrite32(value, ep-fotg210-reg + FOTG210_FIBCR(ep-epnum -
1));
WARNING: line over 80 characters
#441: FILE: drivers/usb/gadget/fotg210-udc.c:334:
+ length = ioread32(ep-fotg210-reg +
FOTG210_FIBCR(ep-epnum - 1));
WARNING: Avoid CamelCase: FIBCR_BCFx
#442: FILE: drivers/usb/gadget/fotg210-udc.c:335:
+ length = FIBCR_BCFx;
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...
to printk(KERN_DEBUG ...
#456: FILE: drivers/usb/gadget/fotg210-udc.c:349:
+ printk(KERN_DEBUG dma_mapping_error\n);
CHECK: Alignment should match open parenthesis
#461: FILE: drivers/usb/gadget/fotg210-udc.c:354:
+ dma_sync_single_for_device(NULL, d, length,
+ ep-dir_in ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
WARNING: line over 80 characters
#476: FILE: drivers/usb/gadget/fotg210-udc.c:369:
+static void fotg210_ep0_queue(struct fotg210_ep *ep, struct fotg210_request
*req)
CHECK: braces {} should be used on all arms of this statement
#483: FILE: drivers/usb/gadget/fotg210-udc.c:376:
+ if (req-req.length) {
[...]
+ } else
[...]
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...
to printk(KERN_DEBUG ...
#486: FILE: drivers/usb/gadget/fotg210-udc.c:379:
+ printk(KERN_DEBUG %s : req-req.length = 0x%x\n,
CHECK: Alignment should match open parenthesis
#487: FILE: drivers/usb/gadget/fotg210-udc.c:380:
+ printk(KERN_DEBUG %s : req-req.length = 0x%x\n,
+ __func__, req-req.length);
CHECK: braces {} should be used on all arms of this statement
#492: FILE: drivers/usb/gadget/fotg210-udc.c:385:
+ if (!req-req.length)
[...]
+ else {
[...]
WARNING: line over 80 characters
#495: FILE: drivers/usb/gadget/fotg210-udc.c:388:
+ u32 value = ioread32(ep-fotg210-reg +
FOTG210_DMISGR0);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...
to printk(KERN_DEBUG ...
#680: FILE: drivers/usb/gadget/fotg210-udc.c:573:
+ printk(KERN_DEBUG 0x%x\n, data);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...
to printk(KERN_DEBUG ...
#691: FILE: drivers/usb/gadget/fotg210-udc.c:584:
+ printk(KERN_DEBUG 0x%x\n, data);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...
to printk(KERN_DEBUG ...
#696: FILE: drivers/usb/gadget/fotg210-udc.c:589:
+ printk(KERN_DEBUG 0x%x\n, data);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...
to printk(KERN_DEBUG ...
#702: FILE: drivers/usb/gadget/fotg210-udc.c:595:
+ printk(KERN_DEBUG 0x%x\n, data);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(...
to printk(KERN_DEBUG ...
#741: FILE: drivers/usb/gadget/fotg210-udc.c:634:
+ printk(KERN_DEBUG request error!!\n);
WARNING: line over 80 characters
#744: FILE: drivers/usb/gadget/fotg210-udc.c:637:
+static void fotg210_set_address(struct fotg210_udc *fotg210, struct
usb_ctrlrequest *ctrl)
Re: [PATCH] usb: gadget: r8a66597-udc: do not unlock unheld spinlock in r8a66597_sudmac_irq()
HI, On Thu, May 30, 2013 at 12:51:37AM +0400, Alexey Khoroshilov wrote: r8a66597_irq() processes sudmac part (r8a66597_sudmac_irq()) before locking r8a66597-lock. But transfer_complete(), that is called inside (r8a66597_sudmac_irq()-sudmac_finish()-transfer_complete()), expects r8a66597-lock is locked. As a result unheld spinlock can be unlocked. The patch just moves locking before calling r8a66597_sudmac_irq(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru should this go to stable ? Looks like this bug has been there since 2.6.32. -- balbi signature.asc Description: Digital signature
Re: usb:is that a bug?
On Mon, May 20, 2013 at 01:17:06PM +0800, linux fddl wrote: Hi, When I used mass_storage as a gadget(use a linux-3.0.77 kernel), With this old kernel, you need to get support from whoever gave you those sources, besides ... (on_end_control_setup_transfer+0x17c/0x298 [f_usb30_udc]) [12251.008045] [7f005300] (on_end_control_setup_transfer+0x0/0x298 [f_usb30_udc]) from [7f00b6bc] (on_usb_ss_function_controller+0x634/0x10b4 [f_usb30_udc]) [12251.008067] r8:fc42 r7:0002 r6:f027754c r5:f027750c r4:f0277400 [12251.008138] [7f00b088] (on_usb_ss_function_controller+0x0/0x10b4 ... based on these function names and ... [f_usb30_udc]) from [80082a20] (handle_irq_event_percpu+0x34/0x160) ... this driver name, I can say that you're using out-of-tree UDC driver. We cannot support that. Good luck -- balbi signature.asc Description: Digital signature
[PATCH] usb: musb: host: fix build warning
very minor patch fixing the following build warning on a debug message: drivers/usb/musb/musb_host.c: In function ‘musb_host_rx’: drivers/usb/musb/musb_host.c:1763:4: warning: format ‘%x’ \ expects argument of type ‘unsigned int’, but argument \ 6 has type ‘dma_addr_t’ [-Wformat] Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/musb/musb_host.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index 1e370ee..47ebde8 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -1760,10 +1760,10 @@ void musb_host_rx(struct musb *musb, u8 epnum) rx_count = musb_readw(epio, MUSB_RXCOUNT); - dev_dbg(musb-controller, RX%d count %d, buffer 0x%x len %d/%d\n, + dev_dbg(musb-controller, RX%d count %d, buffer 0x%llx len %d/%d\n, epnum, rx_count, - urb-transfer_dma - + urb-actual_length, + (unsigned long long) urb-transfer_dma + + urb-actual_length, qh-offset, urb-transfer_buffer_length); -- 1.8.2.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] usb: gadget: r8a66597-udc: do not unlock unheld spinlock in r8a66597_sudmac_irq()
Hi, (2013/05/30 8:58), Felipe Balbi wrote: HI, On Thu, May 30, 2013 at 12:51:37AM +0400, Alexey Khoroshilov wrote: r8a66597_irq() processes sudmac part (r8a66597_sudmac_irq()) before locking r8a66597-lock. But transfer_complete(), that is called inside (r8a66597_sudmac_irq()-sudmac_finish()-transfer_complete()), expects r8a66597-lock is locked. As a result unheld spinlock can be unlocked. The patch just moves locking before calling r8a66597_sudmac_irq(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru should this go to stable ? Looks like this bug has been there since 2.6.32. Because non SMP CPUs have sudmac for now, this may not go to stable, I think. Best regards, Yoshihiro Shimoda -- 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] usb: dwc3: cleanup DWC3_DCTL_LSFTRST bit
On Thu, May 30, 2013 at 01:40:39AM +0800, Felipe Balbi wrote: Hi, On Wed, May 29, 2013 at 02:05:43PM +0800, Huang Rui wrote: Hi Felipe, On Wed, May 29, 2013 at 01:25:59AM +0800, Felipe Balbi wrote: On Tue, May 28, 2013 at 03:42:50PM +0800, Huang Rui wrote: This bit is removed and set as reserved in 2.50a spec. Signed-off-by: Huang Rui ray.hu...@amd.com so ? This driver also works on older versions of the core. What you should do is, perhaps, add a comment saying that this bit shouldn't be used in v2.50a+, then we need to keep an eye for any future users of that bit and make sure that there is proper revision detection around it. Thanks to your reply. I greped codes, in current driver didn't use this bit, and I saw that the bit is marked as reserved in 2.50a spec. I don't confirm this bit should use in v2.50a+, if it will be used or I was wrong, please correct me. I just looked at register mapping, and compared with spec and found this bit is reserved, so I send this patch to remove this define to prevent to confuse. :) it's reserved for 2.50a, what about all the older versions ? What if some older version needs light soft-reset ? I got it, you're right. Thanks to your reminder. Rui -- 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] usb: gadget: add Faraday fotg210_udc driver
Hi,
On Thu, May 30, 2013 at 7:55 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, May 29, 2013 at 06:31:50PM +, Yuan-Hsin Chen wrote:
Faraday fotg210 udc driver supports only Bulk transfer so far.
fotg210 could be configured as an USB2.0 peripheral.
This driver is tested with mass storage gadget driver on Faraday
EVB a369.
Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com
Run through checkpatch.pl --strict and fix all errors, warnings and all
checks which make sense.
WARNING: please write a paragraph that describes the config symbol fully
#81: FILE: drivers/usb/gadget/Kconfig:196:
+config USB_FOTG210_UDC
CHECK: braces {} should be used on all arms of this statement
#183: FILE: drivers/usb/gadget/fotg210-udc.c:76:
+ if (ep-epnum) {
[...]
+ } else
[...]
WARNING: line over 80 characters
#190: FILE: drivers/usb/gadget/fotg210-udc.c:83:
+static void fotg210_fifo_ep_mapping(struct fotg210_ep *ep, u32 epnum, u32
dir_in)
WARNING: line over 80 characters
#237: FILE: drivers/usb/gadget/fotg210-udc.c:130:
+static void fotg210_set_mps(struct fotg210_ep *ep, u32 epnum, u32 mps, u32
dir_in)
WARNING: line over 80 characters
#241: FILE: drivers/usb/gadget/fotg210-udc.c:134:
+ u32 offset = dir_in ? FOTG210_INEPMPSR(epnum) :
FOTG210_OUTEPMPSR(epnum);
WARNING: line over 80 characters
#349: FILE: drivers/usb/gadget/fotg210-udc.c:242:
+static void fotg210_ep_free_request(struct usb_ep *_ep, struct usb_request
*_req)
WARNING: Avoid CamelCase: DMATFNR_ACC_Fn
#372: FILE: drivers/usb/gadget/fotg210-udc.c:265:
+ value |= DMATFNR_ACC_Fn(ep-epnum - 1);
WARNING: line over 80 characters
#418: FILE: drivers/usb/gadget/fotg210-udc.c:311:
+ value = ioread32(ep-fotg210-reg + FOTG210_FIBCR(ep-epnum -
1));
WARNING: line over 80 characters
#420: FILE: drivers/usb/gadget/fotg210-udc.c:313:
+ iowrite32(value, ep-fotg210-reg + FOTG210_FIBCR(ep-epnum -
1));
WARNING: line over 80 characters
#441: FILE: drivers/usb/gadget/fotg210-udc.c:334:
+ length = ioread32(ep-fotg210-reg +
FOTG210_FIBCR(ep-epnum - 1));
WARNING: Avoid CamelCase: FIBCR_BCFx
#442: FILE: drivers/usb/gadget/fotg210-udc.c:335:
+ length = FIBCR_BCFx;
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
#456: FILE: drivers/usb/gadget/fotg210-udc.c:349:
+ printk(KERN_DEBUG dma_mapping_error\n);
CHECK: Alignment should match open parenthesis
#461: FILE: drivers/usb/gadget/fotg210-udc.c:354:
+ dma_sync_single_for_device(NULL, d, length,
+ ep-dir_in ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
WARNING: line over 80 characters
#476: FILE: drivers/usb/gadget/fotg210-udc.c:369:
+static void fotg210_ep0_queue(struct fotg210_ep *ep, struct fotg210_request
*req)
CHECK: braces {} should be used on all arms of this statement
#483: FILE: drivers/usb/gadget/fotg210-udc.c:376:
+ if (req-req.length) {
[...]
+ } else
[...]
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
#486: FILE: drivers/usb/gadget/fotg210-udc.c:379:
+ printk(KERN_DEBUG %s : req-req.length = 0x%x\n,
CHECK: Alignment should match open parenthesis
#487: FILE: drivers/usb/gadget/fotg210-udc.c:380:
+ printk(KERN_DEBUG %s : req-req.length = 0x%x\n,
+ __func__, req-req.length);
CHECK: braces {} should be used on all arms of this statement
#492: FILE: drivers/usb/gadget/fotg210-udc.c:385:
+ if (!req-req.length)
[...]
+ else {
[...]
WARNING: line over 80 characters
#495: FILE: drivers/usb/gadget/fotg210-udc.c:388:
+ u32 value = ioread32(ep-fotg210-reg +
FOTG210_DMISGR0);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
#680: FILE: drivers/usb/gadget/fotg210-udc.c:573:
+ printk(KERN_DEBUG 0x%x\n, data);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
#691: FILE: drivers/usb/gadget/fotg210-udc.c:584:
+ printk(KERN_DEBUG 0x%x\n, data);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
#696: FILE: drivers/usb/gadget/fotg210-udc.c:589:
+ printk(KERN_DEBUG 0x%x\n, data);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
#702: FILE: drivers/usb/gadget/fotg210-udc.c:595:
+ printk(KERN_DEBUG 0x%x\n, data);
WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
#741: FILE: drivers/usb/gadget/fotg210-udc.c:634:
+ printk(KERN_DEBUG request error!!\n);
Re: [PATCH 1/2] USB: xhci: rename ambiguous named XHCI_NEC_HOST to XHCI_NEC_SHOW_FW
Am 30.05.2013 00:25, schrieb Sarah Sharp: On Wed, May 29, 2013 at 11:14:32PM +0200, Alexander Holler wrote: Current Renesas Electronics XHCI hosts (which were formerly NEC) do support the same vendor command to show the firmware. Rename the ambigious named define XHCI_NEC_HOST to XHCI_NEC_SHOW_FW because it's only used to display the firmware version. Besides that, change the output ... NEC firmware version x.y to ... firmware version x.y to not confuse owners of Renesas USB hosts. (so only cosmetic, no functional changes) I'm actually inclined to say you should just rip out the firmware version code entirely. I haven't needed to use it for years, and if Renesas changed their vendor command set, I would rather not submit random commands to the host. So, can you redo this patch to just rip out XHCI_NEC_HOST and everything that uses it? Hmm, I find the firmware version rather informational and would even display it unconditionally (instead of with xhci_debug). It prevents the need to boot Windows to checkout if the latest version is installed, especially if someone is hunting a bug. I just dont't like the name, because e.g. in my case, it made me to have a deeper look at what that quirk does, because I had the hope it might solve a problem. Therefor I think it's useful to rename it. Regards, Alexander Holler -- 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
