Re: [PATCH v1 2/3] usb: phy: convert gpio-vbus to gpio_desc
On Sun, Nov 2, 2014 at 7:11 PM, Robert Jarzmik wrote: > In order to prepare device-tree conversion, port gpio_vbus to use > gpio_desc. > > Signed-off-by: Robert Jarzmik Acked-by: Philipp Zabel regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbserial / ftdi_sio (+ others) bug?
On Mon, Nov 03, 2014 at 11:46:09PM +0200, Janne Huttunen wrote: > On Wed, 29 Oct 2014 09:51:28 +0100 > Johan Hovold wrote: > > Having the driver not reporting overrun (and other) errors will > > obviously not fix the underlying issue with your device, which is > > generating all these errors in the first place. > > Ok, I did take a closer look at this (mostly with usbmon) and it seems > to be caused by the hardware. When the application does open the device > and the driver submits the first bulk reads, there's basically three > possibilities what happens next: > > 1. The chip responds with correct data and everything works fine from >there until the device is closed. > 2. The chip responds with single correct character followed by a few >hundred or so replies containing only the overrun status (no data) >which are then converted to a bunch of binary zeroes by the ldisc >because of the bug I mentioned earlier. After that the chip starts >responding with proper data again and works until closed. Note that the only "bug" is that the application cannot disable the overrun reporting, but why would you want that? The data stream is already corrupt (missing data) so the extra NULL-byte doesn't do much harm, but does provide a hint about what went wrong. > 3. The chip hangs forever without ever responding anything on the >bulk endpoint. > > As a rough estimate I'd say that something like at least one out of > ten opens currently exhibits either behavior 2 or 3. Also it doesn't > seem to have anything to do with any real buffering inside the chip > i.e. if I close a working connection and immediately open it again, > it may hang the chip. What's on the other side of the FTDI chip? > After some poking around, it seems that the chip really doesn't like > the latency timer value of 1 when it is reset. After it gets the data > going it doesn't seem to mind it i.e. I have not seen the chip to > hang or report superfluous overruns during normal operation even with > latency timer value of 1. With timer value 2 I did get something like > 300 opens before hitting the issue and with value 3 I have not seen > the device misbehave (yet) in like a thousand or so opens. I do think > that more testing is still needed before saying anything definite, > but larger timer at least seems to mitigate the issue significantly. That's interesting, and does indeed point to the FTDI chip. > BTW, in case nobody else is ever experiencing this issue, please note > that I cannot guarantee in any way that the FT232RL in my device is > actually authentic. If it is counterfeit, it is a different one than > the one that was having the issue with the Windows driver lately. My > device doesn't seem to have that bug, but that is no guarantee that > it is the real deal. And obviously, real or not, it *does* have some > bug that causes it to now misbehave during open(). > > So, tentatively seems that in order to get rid of the issue with at > least this FT232 variant (whatever it may happen to be), either the > minimum latency timer value should be increased or possibly > alternatively the chip could be reset with higher value and the actual > value set later when the chip has started properly. Although I don't > yet know for sure which latency value would work 100% of the time or > if the alternative idea would actually work at all (I just thought > about trying something like that). You know that you can change the latency-timer setting from user space? setserial /dev/ttyUSBx ^low_latency echo 16 >/sys/class/tty/ttyUSBx/device/latency_timer It still sounds like your hardware is broken, but at least you seem to have found a work-around. Perhaps you can report it to the logging-device (?) manufacturer or FTDI. What is the "lsusb -v" output for your device by the way. Thanks, Johan -- 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 v1 1/3] usb: phy: device-tree documentation for gpio-vbus
Hi Robert,
On Sun, Nov 2, 2014 at 7:11 PM, Robert Jarzmik wrote:
> Add documentation for device-tree binding of the generic gpio-vbus phy
> controller.
>
> Signed-off-by: Robert Jarzmik
> Cc: devicet...@vger.kernel.org
> ---
> .../devicetree/bindings/phy/gpio-vbus.txt | 23
> ++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/gpio-vbus.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/gpio-vbus.txt
> b/Documentation/devicetree/bindings/phy/gpio-vbus.txt
> new file mode 100644
> index 000..ffcfd35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/gpio-vbus.txt
> @@ -0,0 +1,23 @@
> +GPIO VBus phy
> +=
> +
> +gpio-vbus is a phy controller supporting VBus detection and pullup
> activation on
> +GPIOs.
Maybe duplicate the comment from the driver here how his is about
B peripheral only devices
> +Required properties:
> +- compatible : should be "generic,phy-gpio-vbus"
I'm not sure about the compatible value. I have not seen the "generic,"
vendor prefix, and all the other generic gpio-something bindings don't
use any prefix: "gpio-gate-clock", "gpio-leds", "gpio-beeper",
"pps-gpio", etc.
> +- #phy-cells : from the generic PHY bindings, must be 1.
> +- gpios : set of 2 gpio properties (see gpio.txt for gpio properties
> format)
> + first gpio is required, it's the VBus sensing input gpio
> + second gpio is optional, it's the D+ pullup controlling output
> + gpio
> +
> +Optional properties:
> +- wakeup : boolean, if true the VBus gpio will wakeup the platform
The vbus_draw regulator should be part of this binding, I think.
> +Example:
> + usb2phy : gpio-vbus@13 {
> + compatible = "generic,phy-gpio-vbus";
> + gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> + wakeup;
This on the other hand might be too generic.
I'd like to see just wakeup used here, but the other bindings prefix
"linux," (or "gpio-key,").
regards
Philipp
--
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 v1 3/3] usb: phy: add device-tree support for gpio-vbus
Hi Robert,
On Sun, Nov 2, 2014 at 7:11 PM, Robert Jarzmik wrote:
> Add device-tree support for the generic gpio-vbus driver.
>
> Signed-off-by: Robert Jarzmik
> Cc: devicet...@vger.kernel.org
> ---
> drivers/usb/phy/phy-gpio-vbus-usb.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/usb/phy/phy-gpio-vbus-usb.c
> b/drivers/usb/phy/phy-gpio-vbus-usb.c
> index d302ab2..6194728 100644
> --- a/drivers/usb/phy/phy-gpio-vbus-usb.c
> +++ b/drivers/usb/phy/phy-gpio-vbus-usb.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -254,6 +255,12 @@ static int gpio_vbus_probe(struct platform_device *pdev)
> }
> gpiod = gpio_to_desc(gpio);
> wakeup = pdata->wakeup;
> + } else {
> + gpiod = devm_gpiod_get_index(&pdev->dev, NULL, 0, GPIOD_IN);
> + if (pdev->dev.of_node &&
> + of_get_property(pdev->dev.of_node,
> + "wakeup", NULL))
> + wakeup = 1;
> }
> if (!gpiod)
> return -EINVAL;
> @@ -309,6 +316,8 @@ static int gpio_vbus_probe(struct platform_device *pdev)
> gpiod = gpio_to_desc(gpio);
> gpiod_direction_output(gpiod, 0);
> }
> + } else {
> + gpiod = devm_gpiod_get_index(&pdev->dev, NULL, 1, 0);
The pdata path has gpiod_direction_output(gpiod, 0), so should't the flag here
be GPIOD_OUT_LOW?
> }
> if (!IS_ERR(gpiod))
> gpio_vbus->gpiod_pullup = gpiod;
> @@ -382,12 +391,18 @@ static const struct dev_pm_ops gpio_vbus_dev_pm_ops = {
> };
> #endif
>
> +static struct of_device_id gpio_vbus_dt_ids[] = {
> + { .compatible = "generic,phy-gpio-vbus" },
See my reply to the binding docs, I think the "generic," might have to go.
regards
Philipp
--
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: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on arndale platform
Hello Riku, Interesting, as the commit itself is a revert from a kernel back to 2.6 somewhere. The problem I had is related to the PHY being reset on interface-up, can you confirm that you require this? Reverting this breaks ethtool support in turn. Kind regards, Michel Stam -Original Message- From: Riku Voipio [mailto:riku.voi...@iki.fi] Sent: Tuesday, November 04, 2014 8:23 AM To: da...@davemloft.net; Stam, Michel [FINT] Cc: linux-usb@vger.kernel.org; net...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-samsung-...@vger.kernel.org Subject: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on arndale platform Hi, With 3.18-rc3, asix on arndale (samsung exynos 5250 based board), fails to work. Interface is initialized but network traffic seem not to pass through. With kernel IP config the result looks like: [3.323275] usb 3-3.2.4: new high-speed USB device number 4 using exynos-ehci [3.419151] usb 3-3.2.4: New USB device found, idVendor=0b95, idProduct=772a [3.424735] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [3.432196] usb 3-3.2.4: Product: AX88772 [3.436279] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp. [3.441486] usb 3-3.2.4: SerialNumber: 01 [3.447530] asix 3-3.2.4:1.0 (unnamed net_device) (uninitialized): invalid hw address, using random [3.764352] asix 3-3.2.4:1.0 eth0: register 'asix' at usb-1211.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, de:a2:66:bf:ca:4f [4.488773] asix 3-3.2.4:1.0 eth0: link down [5.690025] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1 [5.712947] Sending DHCP requests .. timed out! [ 83.165303] IP-Config: Retrying forever (NFS root)... [ 83.170397] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1 [ 83.192944] Sending DHCP requests . Similar results also with dhclient. Git bisect identified the breaking commit as: commit 3cc81d85ee01e5a0b7ea2f4190e2ed1165f53c31 Author: Michel Stam Date: Thu Oct 2 10:22:02 2014 +0200 asix: Don't reset PHY on if_up for ASIX 88772 Taking 3.18-rc3 and that commit reverted, network works again: [3.303500] usb 3-3.2.4: new high-speed USB device number 4 using exynos-ehci [3.399375] usb 3-3.2.4: New USB device found, idVendor=0b95, idProduct=772a [3.404963] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [3.412424] usb 3-3.2.4: Product: AX88772 [3.416508] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp. [3.421715] usb 3-3.2.4: SerialNumber: 01 [3.427755] asix 3-3.2.4:1.0 (unnamed net_device) (uninitialized): invalid hw address, using random [3.744837] asix 3-3.2.4:1.0 eth0: register 'asix' at usb-1211.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, 12:59:f1:a8:43:90 [7.098998] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1 [7.118258] Sending DHCP requests ., OK [9.753259] IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.111 There might something wrong on the samsung platform code (I understand the USB on arndale is "funny"), but this is still an regression from 3.17. Riku -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] usb: xhci: Revert "xhci: clear root port wake on bits if controller isn't wake-up capable"
This reverts commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
Commit ff8cbf250b448aac35589f6075082c3fcad8a8fe triggers the bug logged at
https://bugzilla.kernel.org/show_bug.cgi?id=85701
Reported-by: Dmitry Nezhevenko
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci-hub.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 696160d..388cfd8 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,7 +22,6 @@
#include
-#include
#include
#include "xhci.h"
@@ -1149,9 +1148,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd->self.root_hub->do_remote_wakeup
- && device_may_wakeup(hcd->self.controller)) {
-
+ if (hcd->self.root_hub->do_remote_wakeup) {
if (t1 & PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 &= ~PORT_WKCONN_E;
--
1.9.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 v2 3/3] usb: xhci: fix comment for PORT_DEV_REMOVE
According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means "Device is non-removable".
Reported-by: Juro Bystricky
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index df76d64..66c168a9 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -358,7 +358,7 @@ struct xhci_op_regs {
/* wake on over-current (enable) */
#define PORT_WKOC_E(1 << 27)
/* bits 28:29 reserved */
-/* true: device is removable - for USB 3.0 roothub emulation */
+/* true: device is non-removable - for USB 3.0 roothub emulation */
#define PORT_DEV_REMOVE(1 << 30)
/* Initiate a warm port reset - complete when PORT_WRC is '1' */
#define PORT_WR(1 << 31)
--
1.9.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: [RFC RESEND 00/10] Create separate header for ehci-dbgp driver
2014-11-03 4:07 GMT+01:00 Chris Rorvick: > fusbh200: Make Xen notificaiton consistent with EHCI > fotg210: Make Xen notificaiton consistent with EHCI you may want to fix the spelling: s/notificaiton/notification/ -- Daniele Forsi -- 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: simple: add Google simple serial SubClass support
On Mon, Nov 03, 2014 at 10:59:59AM -0800, Benson Leung wrote: > On Mon, Nov 3, 2014 at 8:43 AM, Anton Staaf wrote: > > Add support for Google devices that export simple serial > > interfaces using the vendor specific SubClass/Protocol pair > > 0x50/0x01. > > > > Signed-off-by: Anton Staaf > > Reviewed-by: Benson Leung Applied to next, thanks. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Rework "xhci: clear root port wake on bits if controller isn't wake-up capable"
This serie of patch reworks commit ff8cbf250b448aac35589f6075082c3fcad8a8fe. This has been discussed at http://www.spinics.net/lists/linux-usb/msg114986.html It also includes a patch to fix a comment in drivers/usb/host/xhci.h. Changes in v2: * Should not be a quirk. * Should be applied to all xhci controllers. Lu Baolu (3): usb: xhci: Revert "xhci: clear root port wake on bits if controller isn't wake-up capable" usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe usb: xhci: fix comment for PORT_DEV_REMOVE drivers/usb/host/xhci-hub.c | 5 + drivers/usb/host/xhci-pci.c | 42 ++ drivers/usb/host/xhci.h | 8 +++- 3 files changed, 50 insertions(+), 5 deletions(-) -- 1.9.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 v2 2/3] usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe
xhci: clear root port wake on bits if controller isn't wake-up capable
When system is being suspended, if host device is not wakeup capable,
xhci_suspend() needs to clear all root port wake on bits. Otherwise,
some platforms may generate spurious wakeup, even if PCI PME# is dis-
abled.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..cd57aae 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -35,6 +35,8 @@
#define DRIVER_AUTHOR "Sarah Sharp"
#define DRIVER_DESC "'eXtensible' Host Controller (xHC) Driver"
+#definePORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
+
/* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared */
static int link_quirk;
module_param(link_quirk, int, S_IRUGO | S_IWUSR);
@@ -851,6 +853,42 @@ static void xhci_clear_command_ring(struct xhci_hcd *xhci)
xhci_set_cmd_ring_deq(xhci);
}
+static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
+{
+ int port_index;
+ __le32 __iomem **port_array;
+ unsigned long flags;
+ u32 t1, t2;
+
+ spin_lock_irqsave(&xhci->lock, flags);
+
+ /* disble usb3 ports Wake bits*/
+ port_index = xhci->num_usb3_ports;
+ port_array = xhci->usb3_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t2 = xhci_port_state_to_neutral(t1);
+ t2 &= ~PORT_WAKE_BITS;
+ t1 = xhci_port_state_to_neutral(t1);
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ /* disble usb2 ports Wake bits*/
+ port_index = xhci->num_usb2_ports;
+ port_array = xhci->usb2_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t2 = xhci_port_state_to_neutral(t1);
+ t2 &= ~PORT_WAKE_BITS;
+ t1 = xhci_port_state_to_neutral(t1);
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ spin_unlock_irqrestore(&xhci->lock, flags);
+}
+
/*
* Stop HC (not bus-specific)
*
@@ -868,6 +906,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
xhci->shared_hcd->state != HC_STATE_SUSPENDED)
return -EINVAL;
+ /* Clear root port wake on bits if not wakeup capable. */
+ if (!device_may_wakeup(hcd->self.controller))
+ xhci_disable_port_wake_on_bits(xhci);
+
/* Don't poll the roothubs on bus suspend. */
xhci_dbg(xhci, "%s: stopping port polling.\n", __func__);
clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
--
1.9.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 00/10] MA USB drivers cover letter
[added linux-usb@vger.kernel.org Cc] Stephanie Wallick writes: > Media Agnostic (MA) USB enables the USB protocol to be used over a wide > range of physical media. MA USB is a relatively new protocol and is > currently unsupported in the Linux kernel. This patch set adds the > following drivers with the following capabilities: > > 1) MA USB Host: > - provides functionality of a USB Host Controller. > - implements MA USB protocol for a MA USB host. > - provides MA USB packet transport over TCP > > 2) MA USB Device: > - provides functionality of a USB Device Controller. > - implements MA USB protocol for a MA USB device. > - provides MA USB packet transport over TCP Nice. But don't you think this deserves the attention of the linux-usb mailing list? Yes, Greg's attention is of course good to have too :-) But I believe this is of interest to more people, who might not read everything on linux-kernel. Has there been any thought/discussion about the relationship to the existing usbip drivers, which just moved out of staging? Is a usbip userspace compatibility layer feasible sometime in the future? Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on arndale platform
On Tue, Nov 04, 2014 at 09:19:26AM +0100, Stam, Michel [FINT] wrote: > Interesting, as the commit itself is a revert from a kernel back to 2.6 > somewhere. The problem I had is related to the PHY being reset on > interface-up, can you confirm that you require this? I can't confirm what exactly is needed on arndale. I'm neither expert in USB or ethernet. However, I can confirm that without the PHY reset, networking doesn't work on arndale. I now see someone else has the same problem, adding Charles to CC. http://www.spinics.net/lists/linux-usb/msg116656.html > Reverting this > breaks ethtool support in turn. Fixing a bug (ethtool support) must not cause breakage elsewhere (in this case on arndale). This is now a regression of functionality from 3.17. I think it would better to revert the change now and with less hurry introduce a ethtool fix that doesn't break arndale. > Kind regards, > > Michel Stam > > -Original Message- > From: Riku Voipio [mailto:riku.voi...@iki.fi] > Sent: Tuesday, November 04, 2014 8:23 AM > To: da...@davemloft.net; Stam, Michel [FINT] > Cc: linux-usb@vger.kernel.org; net...@vger.kernel.org; > linux-ker...@vger.kernel.org; linux-samsung-...@vger.kernel.org > Subject: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on > arndale platform > > Hi, > > With 3.18-rc3, asix on arndale (samsung exynos 5250 based board), fails > to work. Interface is initialized but network traffic seem not to pass > through. With kernel IP config the result looks like: > > [3.323275] usb 3-3.2.4: new high-speed USB device number 4 using > exynos-ehci > [3.419151] usb 3-3.2.4: New USB device found, idVendor=0b95, > idProduct=772a > [3.424735] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [3.432196] usb 3-3.2.4: Product: AX88772 > [3.436279] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp. > [3.441486] usb 3-3.2.4: SerialNumber: 01 > [3.447530] asix 3-3.2.4:1.0 (unnamed net_device) (uninitialized): > invalid hw address, using random > [3.764352] asix 3-3.2.4:1.0 eth0: register 'asix' at > usb-1211.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, de:a2:66:bf:ca:4f > [4.488773] asix 3-3.2.4:1.0 eth0: link down > [5.690025] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa > 0xC5E1 > [5.712947] Sending DHCP requests .. timed out! > [ 83.165303] IP-Config: Retrying forever (NFS root)... > [ 83.170397] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa > 0xC5E1 > [ 83.192944] Sending DHCP requests . > > Similar results also with dhclient. Git bisect identified the breaking > commit as: > > commit 3cc81d85ee01e5a0b7ea2f4190e2ed1165f53c31 > Author: Michel Stam > Date: Thu Oct 2 10:22:02 2014 +0200 > > asix: Don't reset PHY on if_up for ASIX 88772 > > Taking 3.18-rc3 and that commit reverted, network works again: > > [3.303500] usb 3-3.2.4: new high-speed USB device number 4 using > exynos-ehci > [3.399375] usb 3-3.2.4: New USB device found, idVendor=0b95, > idProduct=772a > [3.404963] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [3.412424] usb 3-3.2.4: Product: AX88772 > [3.416508] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp. > [3.421715] usb 3-3.2.4: SerialNumber: 01 > [3.427755] asix 3-3.2.4:1.0 (unnamed net_device) (uninitialized): > invalid hw address, using random > [3.744837] asix 3-3.2.4:1.0 eth0: register 'asix' at > usb-1211.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, 12:59:f1:a8:43:90 > [7.098998] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa > 0xC5E1 > [7.118258] Sending DHCP requests ., OK > [9.753259] IP-Config: Got DHCP answer from 192.168.1.1, my address > is 192.168.1.111 > > There might something wrong on the samsung platform code (I understand > the USB on arndale is "funny"), but this is still an regression from > 3.17. > > Riku -- 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: dwc3: remove warning of disable scramble check
Some SoC's FPGA platform will need this quirk, but it will complain if running at true SoC platform. This is a normal case, so remove this warning. Signed-off-by: Huang Rui --- Hi, This patch is based on balbi/testing/next branch. Thanks, Rui --- drivers/usb/dwc3/core.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 8ae42b8..3f1f0ab 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -531,9 +531,6 @@ static int dwc3_core_init(struct dwc3 *dwc) dwc->is_fpga = true; } - WARN_ONCE(dwc->disable_scramble_quirk && !dwc->is_fpga, - "disable_scramble cannot be used on non-FPGA builds\n"); - if (dwc->disable_scramble_quirk && dwc->is_fpga) reg |= DWC3_GCTL_DISSCRAMBLE; else -- 1.9.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 1/2] usb: musb: musb_cppi41: recognize HS devices in hostmode
On 10/31/2014 10:40 PM, Sergei Shtylyov wrote:
>> @@ -264,7 +265,14 @@ static void cppi41_dma_callback(void *private_data)
>>*/
>> controller = cppi41_channel->controller;
>>
>> -if (musb->g.speed == USB_SPEED_HIGH) {
>> +if (is_host_active(musb)) {
>> +if (musb->port1_status & USB_PORT_STAT_HIGH_SPEED)
>> +is_hs = 1;
>
>Indent with tabs, not spaces please...
Thank you for spotting this. vim usually does this properly I have no
idea why it aligned with the bracket here instead.
> WBR, Sergei
>
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v5] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode
From: Todd Poynor usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode Some systems require a mechanism to prevent system to enter into suspend state when USB is connected and enumerated in peripheral mode. This patch provides an interface to hold a wakeupsource to prevent suspend. PHY drivers can use this interface when USB is connected and enumerated in peripheral mode. A timed wakeupsource is temporarily held on USB disconnect events, to allow the rest of the system to react to the USB disconnection (dropping host sessions, updating charger status, etc.) prior to re-allowing suspend. Cc: Kishon Vijay Abraham I Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: linux-ker...@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: Android Kernel Team Cc: John Stultz Cc: Sumit Semwal Cc: Arve Hj?nnev?g Cc: Benoit Goby Signed-off-by: Todd Poynor [kiran: Added context to commit message, squished build fixes from Benoit Goby and Arve Hj?nnev?g, changed wakelocks usage to wakeupsource, merged Todd's refactoring logic and simplified the structures and code and addressed community feedback] Signed-off-by: Kiran Raparthy --- v5: * with the new approach,i was able to chnage only 5 phy drivers as mentioned below to use the wakeupsource funtionality. drivers/phy/phy-omap-control.c drivers/usb/phy/phy-ab8500-usb.c drivers/usb/phy/phy-tahvo.c drivers/usb/phy/phy-mv-usb.c drivers/usb/phy/phy-gpio-vbus-usb.c * Notification method not used any more. * introduced usb_phy_set_event in phy.c to hold wakeupsource * introduced usb_phy_wsource_init/usb_phy_wsource_trash in phy.c to initialize/relese per-PHY wakeupsource.These interfaces called from probe/remove functions of phy drivers. * usb_phy_set_event called from phy drivers where usb enumeration event is handled. * usb_phy_set_event expects usb_phy handle where as phy-omap-control.c provides its own type(omap_control_phy), so directly called __pm_stay_awake and __pm_awake_event from phy-omap-control.c instead of calling usb_phy_set_event. v4: * Temporarily hold wakeupsource patch integrated into main patch. * As per feedback,dropped "enabled" module parameter. * Introduced otgws_otg_usb3_notifications function to handle event notifications from usb3 phy. * Handled wakeupsource initialization,spinlock,registration of notifier block per-PHY. * Updated usb_phy structure. v3: * As per the feedback,no global phy pointer used. * called the one-liner wakeupsource handling calls directly instead of indirect functions implemented in v2. * Removed indirect function get_phy_hook and used usb_get_phy to get the phy handle.. v2: * wakeupsource handling implemeted per-PHY * Implemented wakeupsource handling calls in phy * included Todd's refactoring logic. v1: * changed to "disabled by default" from "enable by default". * Kconfig help text modified * Included better commit text * otgws_nb moved to otg_wakeupsource_init function * Introduced get_phy_hook to handle otgws_xceiv per-PHY Initial RFC: * Included build fix from Benoit Goby and Arve Hj?nnev?g * Removed lock->held field in driver as this mechanism is provided in wakeupsource driver. * wakelock(wl) terminology replaced with wakeup_source(ws). drivers/phy/phy-omap-control.c | 9 ++ drivers/usb/phy/phy-ab8500-usb.c | 17 +++ drivers/usb/phy/phy-gpio-vbus-usb.c | 4 +++ drivers/usb/phy/phy-mv-usb.c | 4 +++ drivers/usb/phy/phy-tahvo.c | 5 drivers/usb/phy/phy.c| 56 include/linux/phy/omap_control_phy.h | 4 +++ include/linux/usb/phy.h | 8 ++ 8 files changed, 107 insertions(+) diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c index 311b4f9..efc629f 100644 --- a/drivers/phy/phy-omap-control.c +++ b/drivers/phy/phy-omap-control.c @@ -24,6 +24,7 @@ #include #include #include +#include #include /** @@ -196,9 +197,12 @@ void omap_control_usb_set_mode(struct device *dev, break; case USB_MODE_DEVICE: omap_control_usb_device_mode(ctrl_phy); + __pm_stay_awake(&ctrl_phy->wsource); break; case USB_MODE_DISCONNECT: omap_control_usb_set_sessionend(ctrl_phy); + __pm_wakeup_event(&ctrl_phy->wsource, + msecs_to_jiffies(TEMPORARY_HOLD_TIME)); break; default: dev_vdbg(dev, "invalid omap control usb mode\n"); @@ -246,6 +250,7 @@ static int omap_control_phy_probe(struct platform_device *pdev) struct resource *res; const struct of_device_id *of_id; struct omap_control_phy *control_phy; + char wsource_name[40]; of_id = of_match_device(of_match_ptr(omap_control_phy_id_table), &pdev->dev); @@ -290,6 +295,10 @@ static int omap_control_phy_probe(struct platform_device *pdev) dev_set_drvdata(control_phy
RE: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on arndale platform
Hello Riku, >Fixing a bug (ethtool support) must not cause breakage elsewhere (in this case on arndale). This is now a regression of functionality from 3.17. > >I think it would better to revert the change now and with less hurry introduce a ethtool fix that doesn't break arndale. I don't fully agree here; I would like to point out that this commit is a revert itself. Fixing the armdale will then cause breakage in other implementations, such as ours. Blankly reverting breaks other peoples' implementations. The PHY reset is the thing that breaks ethtool support, so any fix that appeases all would have to take existing PHY state into account. I'm not an expert on the ASIX driver, nor the MII, but I think this is the cause; drivers/net/usb/asix_devices.c: 361 asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR, BMCR_RESET); 362 asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE, 363 ADVERTISE_ALL | ADVERTISE_CSMA); 364 mii_nway_restart(&dev->mii); I would think that the ADVERTISE_ALL is the cause here, as it will reset the MII back to default, thus overriding ethtool settings. Would an: Int reg; reg = asix_mdio_read(dev->net,dev->mii.phy_id,MII_ADVERTISE); prior to the offending lines, and then; 362 asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE, 363 reg); solve the problem for you guys? Mind, maybe the read function should take into account the reset value of the MII, and set it to ADVERTISE_ALL | ADVERTISE_CSMA. I don't have any documention here at the moment. Is anyone able to confirm my suspicions? Kind regards, Michel Stam -Original Message- From: Riku Voipio [mailto:riku.voi...@iki.fi] Sent: Tuesday, November 04, 2014 10:44 AM To: Stam, Michel [FINT] Cc: Riku Voipio; da...@davemloft.net; linux-usb@vger.kernel.org; net...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-samsung-...@vger.kernel.org; ckee...@opensource.wolfsonmicro.com Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on arndale platform On Tue, Nov 04, 2014 at 09:19:26AM +0100, Stam, Michel [FINT] wrote: > Interesting, as the commit itself is a revert from a kernel back to > 2.6 somewhere. The problem I had is related to the PHY being reset on > interface-up, can you confirm that you require this? I can't confirm what exactly is needed on arndale. I'm neither expert in USB or ethernet. However, I can confirm that without the PHY reset, networking doesn't work on arndale. I now see someone else has the same problem, adding Charles to CC. http://www.spinics.net/lists/linux-usb/msg116656.html > Reverting this > breaks ethtool support in turn. Fixing a bug (ethtool support) must not cause breakage elsewhere (in this case on arndale). This is now a regression of functionality from 3.17. I think it would better to revert the change now and with less hurry introduce a ethtool fix that doesn't break arndale. > Kind regards, > > Michel Stam > > -Original Message- > From: Riku Voipio [mailto:riku.voi...@iki.fi] > Sent: Tuesday, November 04, 2014 8:23 AM > To: da...@davemloft.net; Stam, Michel [FINT] > Cc: linux-usb@vger.kernel.org; net...@vger.kernel.org; > linux-ker...@vger.kernel.org; linux-samsung-...@vger.kernel.org > Subject: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on > arndale platform > > Hi, > > With 3.18-rc3, asix on arndale (samsung exynos 5250 based board), > fails to work. Interface is initialized but network traffic seem not > to pass through. With kernel IP config the result looks like: > > [3.323275] usb 3-3.2.4: new high-speed USB device number 4 using > exynos-ehci > [3.419151] usb 3-3.2.4: New USB device found, idVendor=0b95, > idProduct=772a > [3.424735] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [3.432196] usb 3-3.2.4: Product: AX88772 > [3.436279] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp. > [3.441486] usb 3-3.2.4: SerialNumber: 01 > [3.447530] asix 3-3.2.4:1.0 (unnamed net_device) (uninitialized): > invalid hw address, using random > [3.764352] asix 3-3.2.4:1.0 eth0: register 'asix' at > usb-1211.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet, de:a2:66:bf:ca:4f > [4.488773] asix 3-3.2.4:1.0 eth0: link down > [5.690025] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa > 0xC5E1 > [5.712947] Sending DHCP requests .. timed out! > [ 83.165303] IP-Config: Retrying forever (NFS root)... > [ 83.170397] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex, lpa > 0xC5E1 > [ 83.192944] Sending DHCP requests . > > Similar results also with dhclient. Git bisect identified the breaking > commit as: > > commit 3cc81d85ee01e5a0b7ea2f4190e2ed1165f53c31 > Author: Michel Stam > Date: Thu Oct 2 10:22:02 2014 +0200 > > asix: Don't reset PHY on if_up for ASIX 88772 > > Taking 3.18-rc3 and that commit reverted, network works again: > > [3.303500] usb 3-3.2.4: n
RE: [PATCH] usb: gadget: don't create new string_container if already exist
> -Original Message-
> From: Andrzej Pietrasiewicz [mailto:andrze...@samsung.com]
> Sent: 2014年10月28日 21:10
> To: Neil Zhang; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: ba...@ti.com; gre...@linuxfoundation.org
> Subject: Re: [PATCH] usb: gadget: don't create new string_container if already
> exist
>
> Hi,
>
> W dniu 28.10.2014 o 12:33, Neil Zhang pisze:
> > Don't create new usb_gadget_string_container if the current strings
> > are already exist in the usb_composite_dev.
> > Otherwise the ids_tab will overflow soon if we bind / unbind usb
> > functions frequently like android does.
>
> The problem you are describing does not exist in mainline kernel, where
> functions are always unbound as part of the whole gadget's unbind - regardless
> of whether it is a legacy gadget or configfs-composed gadget. When the whole
> gadget is unbound, composite_dev_cleanup() is called which zeroes cdev-
> >next_string_id and frees all gadget strings containers.
>
Yes, you are right that the current mainline won't suffer this issue.
But it will be needed if we want to implement similar features like android do.
It will only remove config rather than whole gadget driver.
> >
> > Signed-off-by: Neil Zhang
> > ---
> > drivers/usb/gadget/composite.c |6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/usb/gadget/composite.c
> > b/drivers/usb/gadget/composite.c index a8c18df..6fe3c6b 100644
> > --- a/drivers/usb/gadget/composite.c
> > +++ b/drivers/usb/gadget/composite.c
> > @@ -1183,6 +1183,12 @@ struct usb_string *usb_gstrings_attach(struct
> usb_composite_dev *cdev,
> > if (!n_gstrings)
> > return ERR_PTR(-EINVAL);
> >
> > + list_for_each_entry(uc, &cdev->gstrings, list) {
> > + n_gs = get_containers_gs(uc);
> > + if (!strcmp(n_gs[0]->strings[0].s, sp[0]->strings[0].s))
>
> To me it looks like it is a big assumption that if the first string matches,
> the rest are the same, too. Isn't it?
>
> Anyway, this solution looks more like pushing the moment when cdev-
> >next_string_id becomes 254 to a later time rather than preventing such a
> situation.
>
> If usb_gstrings_attach() happens at function bind time, perhaps there should
> be some usb_gstrings_detach() called at function unbind?
>
> AP
Best Regards,
Neil Zhang
Re: [PATCH] usb: gadget: don't create new string_container if already exist
W dniu 04.11.2014 o 12:05, Neil Zhang pisze: -Original Message- From: Andrzej Pietrasiewicz [mailto:andrze...@samsung.com] Sent: 2014年10月28日 21:10 To: Neil Zhang; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org Cc: ba...@ti.com; gre...@linuxfoundation.org Subject: Re: [PATCH] usb: gadget: don't create new string_container if already exist The problem you are describing does not exist in mainline kernel, where functions are always unbound as part of the whole gadget's unbind - regardless of whether it is a legacy gadget or configfs-composed gadget. When the whole gadget is unbound, composite_dev_cleanup() is called which zeroes cdev- next_string_id and frees all gadget strings containers. Yes, you are right that the current mainline won't suffer this issue. But it will be needed if we want to implement similar features like android do. What features do you think of? Mainlining the android gadget has been attempted a number of times and is unlikely to succeed. A configurable gadget can be composed with configfs interface, so no need to add anything new. That said, I think that the proper way of eliminating the problem described is freeing the resources on function unbind rather than preventing composite from allocating more (duplicate) resources on bind, which your patch does. AP -- 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: option: Add ID for Peiker LTE NAD
Matthias Klein writes:
> Am 02.11.2014 um 04:35 schrieb Lars Melin:
>> On 2014-11-01 23:01, Matthias Klein wrote:
>>> Add ID of the Peiker LTE NAD for legacy serial interface
>>>
>>> Signed-off-by: Matthias Klein
>>> ---
>>> drivers/usb/serial/option.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
>>> index d1a3f60..d7f1042 100644
>>> --- a/drivers/usb/serial/option.c
>>> +++ b/drivers/usb/serial/option.c
>>> @@ -1091,6 +1091,7 @@ static const struct usb_device_id option_ids[] = {
>>> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE
>>> MF330 */
>>> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
>>> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
>>> +{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9025)}, /* Peiker LTE NAD */
>>> { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
>>> { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
>>> { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
>> 05c6:9025 already has its net interface (#4) supported by the
>> qmi_wwan driver so your patch is wrong.
>> There is also an ADB interface which I don't think should be driven
>> by option.
>>
>>
> The ID is right, and it can be used with the option driver or qmi_wwan.
> Ignore my patch, I will move to qmi_wwan in the future ...
The serial functions should still be supported by the option driver.
Both serial and QMI can be used at the same time, and applications like
ModemManager will take advantage of this.
What you need to to is to make sure the option driver ignores all the
USB interfaces it cannot handle. How to best do that depends on the
descriptors - specifically which class codes they use.
"lsusb -vd 05c6:9025" should tell you more about that.
Assuming that all serial interfaces and the QMI interface all use
ff/ff/ff, while the ADB interface probably use ff/42/01, then something
like this should work:
{ USB_DEVICE_AND_INTERFACE_INFO(QUALCOMM_VENDOR_ID, 0x9025, 0xff, 0xff,
0xff), /* Peiker LTE NAD */
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] serial: Fix Entrega company name spelling
Hi Greg, On Mon, 3 Nov 2014 15:23:36 -0800 Greg KH wrote: > On Sat, Oct 04, 2014 at 12:19:59PM +0100, Mark Knibbs wrote: > > ... > > I see a bunch of patches from you in my queue, but I'm confused as to > which ones I should apply, and which I should ignore. > > Can you resend what I should apply please? Also, should I have reverted > a previous patch I applied? If so, what is the git commit id of it? Commit bda9893c50fb56253d3c206c14e3f933e5f68b3c "storage: Replace magic number with define in usb_stor_euscsi_init()" should be reverted. Patches which could/should be applied are: Update default usb-storage delay_use value in kernel-parameters.txt storage: Fix bus scan and multi-LUN support for SCM eUSCSI devices [v2] serial: Fix Entrega company name spelling [v2] storage: Reject bogus max LUN values [v2] storage: Fix timeout in usb_stor_euscsi_init() and usb_stor_huawei_e220_init() [v3] storage: Enable multi-target mode as vendor driver does for SCM eUSCSI bridge I'll resend all those. Mark -- 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][RESEND] Update default usb-storage delay_use value in kernel-parameters.txt
Hi, Back in 2010 the default usb-storage delay_use time was reduced from 5 to 1 second (commit a4a47bc03fe520e95e0c4212bf97c86545fb14f9), but kernel-parameters.txt wasn't updated to reflect that. Signed-off-by: Mark Knibbs --- diff -upN linux-3.17/Documentation/kernel-parameters.txt.orig linux-3.17/Documentation/kernel-parameters.txt --- linux-3.17/Documentation/kernel-parameters.txt.orig 2014-10-05 20:23:04.0 +0100 +++ linux-3.17/Documentation/kernel-parameters.txt 2014-10-10 13:51:16.0 +0100 @@ -3502,7 +3502,7 @@ bytes respectively. Such letter suffixes usb-storage.delay_use= [UMS] The delay in seconds before a new device is - scanned for Logical Units (default 5). + scanned for Logical Units (default 1). usb-storage.quirks= [UMS] A list of quirks entries to supplement or -- 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][RESEND] storage: Reject bogus max LUN values
Hi,
Some mass storage devices return a bogus value in response to a Get Max LUN
request. The Iomega Jaz USB Adapter responds with 0x10, hence my recent
patch to use the US_FL_SINGLE_LUN quirk for it.
The USB MSC Bulk Only Transport document says "The device shall return one
byte of data that contains the maximum LUN supported by the device."
Since the LUN field in the command block wrapper is only 4 bits wide, it
might be helpful to report too-large LUN values in the kernel log, and
assume max LUN is actually 0. That could get some devices which currently
need the US_FL_SINGLE_LUN quirk to work.
Signed-off-by: Mark Knibbs
Acked-by: Alan Stern
---
v2: Minor change as suggested
diff -upN linux-3.17/drivers/usb/storage/transport.c.orig
linux-3.17/drivers/usb/storage/transport.c
--- linux-3.17/drivers/usb/storage/transport.c.orig 2014-10-05
20:12:36.0 +0100
+++ linux-3.17/drivers/usb/storage/transport.c 2014-10-12 13:11:38.0
+0100
@@ -1035,9 +1035,20 @@ int usb_stor_Bulk_max_lun(struct us_data
usb_stor_dbg(us, "GetMaxLUN command result is %d, data is %d\n",
result, us->iobuf[0]);
- /* if we have a successful request, return the result */
- if (result > 0)
- return us->iobuf[0];
+ /*
+* If we have a successful request, return the result if valid. The
+* CBW LUN field is 4 bits wide, so the value reported by the device
+* should fit into that.
+*/
+ if (result > 0) {
+ if (us->iobuf[0] < 16) {
+ return us->iobuf[0];
+ } else {
+ dev_info(&us->pusb_intf->dev,
+"Max LUN %d is not valid, using 0 instead",
+us->iobuf[0]);
+ }
+ }
/*
* Some devices don't like GetMaxLUN. They may STALL the control
--
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][RESEND] storage: Fix timeout in usb_stor_euscsi_init() and usb_stor_huawei_e220_init()
Hi, The timeout argument to usb_stor_control_msg() is specified in jiffies, not milliseconds. Signed-off-by: Mark Knibbs --- v2: Add spaces, e.g. 5*HZ --> 5 * HZ After the recent linux-usb mailing list thread "usb_stor_control_msg() timeout argument", the usb_control_msg() timeout argument is given in milliseconds, but the usb_stor_control_msg() timeout is in jiffies. diff -up linux-3.17/drivers/usb/storage/initializers.c.orig linux-3.17/drivers/usb/storage/initializers.c --- linux-3.17/drivers/usb/storage/initializers.c.orig 2014-10-05 20:23:04.0 +0100 +++ linux-3.17/drivers/usb/storage/initializers.c 2014-10-17 21:01:49.063077637 +0100 @@ -52,7 +52,7 @@ int usb_stor_euscsi_init(struct us_data us->iobuf[0] = 0x1; result = usb_stor_control_msg(us, us->send_ctrl_pipe, 0x0C, USB_RECIP_INTERFACE | USB_TYPE_VENDOR, - 0x01, 0x0, us->iobuf, 0x1, 5000); + 0x01, 0x0, us->iobuf, 0x1, 5 * HZ); usb_stor_dbg(us, "-- result is %d\n", result); return 0; @@ -100,7 +100,7 @@ int usb_stor_huawei_e220_init(struct us_ result = usb_stor_control_msg(us, us->send_ctrl_pipe, USB_REQ_SET_FEATURE, USB_TYPE_STANDARD | USB_RECIP_DEVICE, - 0x01, 0x0, NULL, 0x0, 1000); + 0x01, 0x0, NULL, 0x0, 1 * HZ); usb_stor_dbg(us, "Huawei mode set result is %d\n", result); return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3][RESEND] storage: Enable multi-target mode as vendor driver does for SCM eUSCSI bridge
usb_stor_euscsi_init() enables multi-target mode for SCM eUSB SCSI bridge devices. The control message it sends has wLength = 1 and the byte sent is 0x01. While that works, the SCM Windows driver does it with wLength = 0. We may as well match what the SCM driver does. Signed-off-by: Mark Knibbs --- This includes a change from [PATCH v2] storage: Fix timeout in usb_stor_euscsi_init() and usb_stor_huawei_e220_init() v3: Add spaces, 5*HZ --> 5 * HZ v2: Remove incorrect use of USB_CTRL_SET_TIMEOUT (=5000); usb_stor_control_msg() timeout argument is actually specified in jiffies. diff -up linux-3.17/drivers/usb/storage/initializers.c.orig linux-3.17/drivers/usb/storage/initializers.c --- linux-3.17/drivers/usb/storage/initializers.c.orig 2014-10-05 20:23:04.0 +0100 +++ linux-3.17/drivers/usb/storage/initializers.c 2014-10-16 13:39:04.497910732 +0100 @@ -49,10 +49,9 @@ int usb_stor_euscsi_init(struct us_data int result; usb_stor_dbg(us, "Attempting to init eUSCSI bridge...\n"); - us->iobuf[0] = 0x1; result = usb_stor_control_msg(us, us->send_ctrl_pipe, 0x0C, USB_RECIP_INTERFACE | USB_TYPE_VENDOR, - 0x01, 0x0, us->iobuf, 0x1, 5000); + 0x01, 0x0, NULL, 0x0, 5 * HZ); usb_stor_dbg(us, "-- result is %d\n", result); return 0; -- 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][RESEND] serial: Fix Entrega company name spelling
Hi,
Entrega is misspelled as Entregra or Entrgra, so fix that.
Signed-off-by: Mark Knibbs
---
v2 change: Fix spelling in usb-serial.txt too.
diff -uprN linux-3.17-rc7 linux-3.17-rc7.new
diff -uprN linux-3.17-rc7/Documentation/usb/usb-serial.txt
linux-3.17-rc7.new/Documentation/usb/usb-serial.txt
--- linux-3.17-rc7/Documentation/usb/usb-serial.txt 2014-09-28
22:29:07.0 +0100
+++ linux-3.17-rc7.new/Documentation/usb/usb-serial.txt 2014-10-04
12:12:43.0 +0100
@@ -145,7 +145,7 @@ Keyspan PDA Serial Adapter
Single port DB-9 serial adapter, pushed as a PDA adapter for iMacs (mostly
sold in Macintosh catalogs, comes in a translucent white/green dongle).
Fairly simple device. Firmware is homebrew.
- This driver also works for the Xircom/Entrgra single port serial adapter.
+ This driver also works for the Xircom/Entrega single port serial adapter.
Current status:
Things that work:
diff -uprN linux-3.17-rc7/drivers/usb/serial/Kconfig
linux-3.17-rc7.new/drivers/usb/serial/Kconfig
--- linux-3.17-rc7/drivers/usb/serial/Kconfig 2014-09-28 22:29:07.0
+0100
+++ linux-3.17-rc7.new/drivers/usb/serial/Kconfig 2014-10-04
11:36:16.0 +0100
@@ -604,10 +604,10 @@ config USB_SERIAL_CYBERJACK
If unsure, say N.
config USB_SERIAL_XIRCOM
- tristate "USB Xircom / Entregra Single Port Serial Driver"
+ tristate "USB Xircom / Entrega Single Port Serial Driver"
select USB_EZUSB_FX2
help
- Say Y here if you want to use a Xircom or Entregra single port USB to
+ Say Y here if you want to use a Xircom or Entrega single port USB to
serial converter device. This driver makes use of firmware
developed from scratch by Brian Warner.
diff -uprN linux-3.17-rc7/drivers/usb/serial/keyspan_pda.c
linux-3.17-rc7.new/drivers/usb/serial/keyspan_pda.c
--- linux-3.17-rc7/drivers/usb/serial/keyspan_pda.c 2014-09-28
22:29:07.0 +0100
+++ linux-3.17-rc7.new/drivers/usb/serial/keyspan_pda.c 2014-10-04
11:43:34.0 +0100
@@ -1,5 +1,5 @@
/*
- * USB Keyspan PDA / Xircom / Entregra Converter driver
+ * USB Keyspan PDA / Xircom / Entrega Converter driver
*
* Copyright (C) 1999 - 2001 Greg Kroah-Hartman
* Copyright (C) 1999, 2000 Brian Warner
@@ -58,11 +58,11 @@ struct keyspan_pda_private {
#define KEYSPAN_PDA_FAKE_ID0x0103
#define KEYSPAN_PDA_ID 0x0104 /* no clue */
-/* For Xircom PGSDB9 and older Entregra version of the same device */
+/* For Xircom PGSDB9 and older Entrega version of the same device */
#define XIRCOM_VENDOR_ID 0x085a
#define XIRCOM_FAKE_ID 0x8027
-#define ENTREGRA_VENDOR_ID 0x1645
-#define ENTREGRA_FAKE_ID 0x8093
+#define ENTREGA_VENDOR_ID 0x1645
+#define ENTREGA_FAKE_ID0x8093
static const struct usb_device_id id_table_combined[] = {
#ifdef KEYSPAN
@@ -70,7 +70,7 @@ static const struct usb_device_id id_tab
#endif
#ifdef XIRCOM
{ USB_DEVICE(XIRCOM_VENDOR_ID, XIRCOM_FAKE_ID) },
- { USB_DEVICE(ENTREGRA_VENDOR_ID, ENTREGRA_FAKE_ID) },
+ { USB_DEVICE(ENTREGA_VENDOR_ID, ENTREGA_FAKE_ID) },
#endif
{ USB_DEVICE(KEYSPAN_VENDOR_ID, KEYSPAN_PDA_ID) },
{ } /* Terminating entry */
@@ -93,7 +93,7 @@ static const struct usb_device_id id_tab
#ifdef XIRCOM
static const struct usb_device_id id_table_fake_xircom[] = {
{ USB_DEVICE(XIRCOM_VENDOR_ID, XIRCOM_FAKE_ID) },
- { USB_DEVICE(ENTREGRA_VENDOR_ID, ENTREGRA_FAKE_ID) },
+ { USB_DEVICE(ENTREGA_VENDOR_ID, ENTREGA_FAKE_ID) },
{ }
};
#endif
@@ -667,7 +667,7 @@ static int keyspan_pda_fake_startup(stru
#endif
#ifdef XIRCOM
else if ((le16_to_cpu(serial->dev->descriptor.idVendor) ==
XIRCOM_VENDOR_ID) ||
-(le16_to_cpu(serial->dev->descriptor.idVendor) ==
ENTREGRA_VENDOR_ID))
+(le16_to_cpu(serial->dev->descriptor.idVendor) ==
ENTREGA_VENDOR_ID))
fw_name = "keyspan_pda/xircom_pgs.fw";
#endif
else {
@@ -744,7 +744,7 @@ static struct usb_serial_driver xircom_p
.owner =THIS_MODULE,
.name = "xircom_no_firm",
},
- .description = "Xircom / Entregra PGS - (prerenumeration)",
+ .description = "Xircom / Entrega PGS - (prerenumeration)",
.id_table = id_table_fake_xircom,
.num_ports =1,
.attach = keyspan_pda_fake_startup,
--
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][RESEND] storage: Fix bus scan and multi-LUN support for SCM eUSCSI devices
This patch does two things for SCM eUSCSI USB-SCSI converters:
1. SCM eUSCSI bridge devices are hard-wired to use SCSI ID 7. On connecting
the converter, access to that ID is attempted during the bus scan. Asking
the converter to issue INQUIRY commands to itself isn't very polite and
wastes time. Set this_id to 7 so __scsi_scan_target() skips it in the scan.
2. Enable multi-LUN support. eUSCSI devices don't support Get Max LUN
requests, returning an error (-32). [Different targets could have different
numbers of LUNs, so it wouldn't make sense to return a particular value in
response to Get Max LUN.]
usb_stor_scan_dwork() does this:
/* For bulk-only devices, determine the max LUN value */
if (us->protocol == USB_PR_BULK && !(us->fflags & US_FL_SINGLE_LUN)) {
mutex_lock(&us->dev_mutex);
us->max_lun = usb_stor_Bulk_max_lun(us);
mutex_unlock(&us->dev_mutex);
It avoids calling usb_stor_Bulk_max_lun() if US_FL_SINGLE_LUN, but not for
US_FL_SCM_MULT_TARG. Since usb_stor_Bulk_max_lun() returns 0 in the error
case, us->max_lun was always set to 0.
[If the user doesn't want multi-LUN support (perhaps there are SCSI devices
which respond to commands on all LUNs?), the US_FL_SINGLE_LUN quirk can be
specified on the kernel command line.]
Signed-off-by: Mark Knibbs
---
diff -up linux-3.17/drivers/usb/storage/usb.c.orig
linux-3.17/drivers/usb/storage/usb.c
--- linux-3.17/drivers/usb/storage/usb.c.orig 2014-10-05 20:23:04.0
+0100
+++ linux-3.17/drivers/usb/storage/usb.c2014-10-16 22:11:31.0
+0100
@@ -877,7 +877,9 @@ static void usb_stor_scan_dwork(struct w
dev_dbg(dev, "starting scan\n");
/* For bulk-only devices, determine the max LUN value */
- if (us->protocol == USB_PR_BULK && !(us->fflags & US_FL_SINGLE_LUN)) {
+ if (us->protocol == USB_PR_BULK &&
+ !(us->fflags & US_FL_SINGLE_LUN) &&
+ !(us->fflags & US_FL_SCM_MULT_TARG)) {
mutex_lock(&us->dev_mutex);
us->max_lun = usb_stor_Bulk_max_lun(us);
mutex_unlock(&us->dev_mutex);
@@ -976,13 +978,24 @@ int usb_stor_probe2(struct us_data *us)
usb_stor_dbg(us, "Transport: %s\n", us->transport_name);
usb_stor_dbg(us, "Protocol: %s\n", us->protocol_name);
+ if (us->fflags & US_FL_SCM_MULT_TARG) {
+ /*
+* SCM eUSCSI bridge devices can have different numbers
+* of LUNs on different targets; allow all to be probed.
+*/
+ us->max_lun = 7;
+ /* The eUSCSI itself has ID 7, so avoid scanning that */
+ us_to_host(us)->this_id = 7;
+ /* max_id is 8 initially, so no need to set it here */
+ } else {
+ /* In the normal case there is only a single target */
+ us_to_host(us)->max_id = 1;
+ }
+
/* fix for single-lun devices */
if (us->fflags & US_FL_SINGLE_LUN)
us->max_lun = 0;
- if (!(us->fflags & US_FL_SCM_MULT_TARG))
- us_to_host(us)->max_id = 1;
-
/* Find the endpoints and calculate pipe values */
result = get_pipes(us);
if (result)
--
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][RESEND] serial: Fix Entrega company name spelling
On Tue, Nov 04, 2014 at 01:00:31PM +, Mark Knibbs wrote: > Hi, > > Entrega is misspelled as Entregra or Entrgra, so fix that. > > Signed-off-by: Mark Knibbs > > --- > v2 change: Fix spelling in usb-serial.txt too. Why are you resending this one which I have already applied? Johan -- 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: remove warning of disable scramble check
On Tue, Nov 04, 2014 at 05:29:51PM +0800, Huang Rui wrote: > Some SoC's FPGA platform will need this quirk, but it will complain if > running at true SoC platform. This is a normal case, so remove this > warning. nope, why do you need disable_scramble on actual SoC ? Without an erratum number I will not accept this, sorry. -- balbi signature.asc Description: Digital signature
Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
Hi,
I wanted to understand what is going on the kernel-side when
connecting to the Internet via a Huawei E173 USB web-stick (3rd
Generation: UMTS / HSPA).
Especially the correlation between the diverse USB/NET kernel-drivers
and how the networking is setup.
I have tested a Ubuntu trusty kernel on my Ubuntu/precise system and
compared the configs to get the stuff run on 3.18-rc2+.
Beyond the "option" driver, I required usb_serial / usb_wwan to be
activated and some more ("cde-ether" or sth. sound similiar...).
( Currently, I am not sitting (it's a Windows machine) in front of my
machine, so I cannot send you my latest kernel-config. )
As usually I looked into Documentation directory.
So, my 1st question where do I get some informations in general on
this topic - usb [1] or net subdirectory (seen from kernel-side)?
I found a usb-serial kernel-doc [1].
( I have no Linux Git source so I cannot grep for patterns. )
The next mystery is what is network-manager doing in the background?
I have seen that modem-manager is invoked, but as said I would like to
understand the "internas" (means check the logs, turn on some
debugging kernel-space/user-space, etc.).
I am not sure but syncing with 3G network seems to take a while since
I really can connect to the Internet.
I am happy about some fruitful informations or web-links...
Thanks in advance.
Regards,
- Sedat -
[1] https://www.kernel.org/doc/Documentation/usb/usb-serial.txt
--
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: Large disk drives
On Tue, 4 Nov 2014, James Bottomley wrote: > On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote: > > Was there any resolution as to how large disk drives would be handled > > if their interface did not support the "capacity" request that would > > tell how large they were? > > Realistically no ... unless someone comes up with a reliable heuristic > to give us the size. I posted a patch to allow the user to override the reported capacity: http://marc.info/?l=linux-scsi&m=140993840113445&w=2 Nobody responded to it. > > Unfortunately, such devices work OK with Windows (since Windows trusts > > what the partition table says), you can't just say to the salesperson > > "It has to work on drives over 3 TB." > > This is a stopgap: your 3TB drive can be guessed as the 16 bit capacity > plus 2TB, but the same won't happen for a 5TB device. Believing the > partition table gives us a chicken and egg problem because something > still has to get the partition table on to the device. > > I don't think "don't buy something that doesn't work" is a hugely > unreasonable response to this. The problem is knowing beforehand whether it will work. Once you buy the device and can test it, returning it is annoying and time-consuming at best. 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: usb media detection issue on USB_MUSB_HDRC on kernel 3.17
Hi all, was switched to other tasks last week and couldn't contribute. Seems MUSB is also broken on OMAP3 boards, booting in OTG mode I'm not able to make it work when a pendrive is connected to the port. Forcing HOST mode I get following messages: [ 13.244567] usb 2-1: new high-speed USB device number 2 using musb-hdrc [ 13.503234] usb 2-1: device v058f p6387 is not supported [ 13.592346] usb usb2-port1: unable to enumerate USB device You need to disable CONFIG_USB_OTG_WHITELIST option to avoid this. Or add your device to white list of supported devices. I don't have actually that option enabled. Thanks, right, with this option disabled I can enumerate the device. OTOH the big problem is OTG doesn't switch between peripheric mode and host mode. The use case is as follows: 1. Start the board with OTG mode, nothing connected to the port. 2. Plug a pendrive with an adaptor that sets the ID pin to low. In that case the no device is detected. I am testing 2 non-working cases: 1) If i set musb to work as HOST only mode, (i am setting this into arch/arm/mach-davinci/usb.c) usb stick is detected and mounted, but, after this i see da8xx_musb_interrupt() routine called continuously spamming the console, until i remove the usb stick. After that, the interrupt is never happening anymore even at a new re-insertion of the stick. 2) If i let the driver as default (OTG), usb stick is properly detected at every insertion and removal, but just after the insertion i receive the VBUS error, but the 5V of course are there (measured). My board(am1808 based) has USB ID connected fixed to ground. I am proceeding on investigations. Regards Angelo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] [usb] make xhci platform driver use 64 bit or 32 bit DMA
The xhci platform driver needs to work on systems that either only
support 64-bit DMA or only support 32-bit DMA. Attempt to set a
coherent dma mask for 64-bit DMA, and attempt again with 32-bit
DMA if that fails.
Signed-off-by: Mark Langsdorf
Tested-by: Mark Salter
---
Changes from v1:
Consolidated to use dma_set_mask_and_coherent
Got rid of the check against sizeof(dma_addr_t)
drivers/usb/host/xhci-plat.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1a0cf9f..91c7557 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,14 +147,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
return ret;
}
- /* Initialize dma_mask and coherent_dma_mask to 32-bits */
- ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
- if (ret)
- return ret;
- if (!pdev->dev.dma_mask)
- pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
- else
- dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
+ ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
+ if (ret) {
+ ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+ }
+
hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
if (!hcd)
--
1.9.3
--
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 2/2] [usb] add support for ACPI identification to xhci-platform
Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.
Signed-off-by: Mark Langsdorf
---
Changes from v1
Renamed from "add support for APM X-Gene to xhci-platform"
Removed changes to arm64/Kconfig
Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
drivers/usb/host/Kconfig | 7 ++-
drivers/usb/host/xhci-plat.c | 11 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a7..060a2361 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -27,7 +27,12 @@ config USB_XHCI_HCD
if USB_XHCI_HCD
config USB_XHCI_PLATFORM
- tristate
+ tristate "xHCI platform driver support"
+ --help--
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.
config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 91c7557..3db47ea 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "xhci.h"
#include "xhci-mvebu.h"
@@ -287,6 +288,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
#endif
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+ /* APM X-Gene USB Controller */
+ { "PNP0D10", },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
+#endif
+
static struct platform_driver usb_xhci_driver = {
.probe = xhci_plat_probe,
.remove = xhci_plat_remove,
@@ -294,6 +304,7 @@ static struct platform_driver usb_xhci_driver = {
.name = "xhci-hcd",
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(usb_xhci_of_match),
+ .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
};
MODULE_ALIAS("platform:xhci-hcd");
--
1.9.3
--
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: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
> Hi,
>
> I wanted to understand what is going on the kernel-side when
> connecting to the Internet via a Huawei E173 USB web-stick (3rd
> Generation: UMTS / HSPA).
>
> Especially the correlation between the diverse USB/NET kernel-drivers
> and how the networking is setup.
General overview: there are many different types of WWAN devices and
they fall into a couple groups:
1) PPP-only via serial ports; IP packets are transmitted via a PPP
interface (eg, ppp0) created after sending some AT commands to the modem
over that serial port. IP addressing happens via PPP's IPCP/IPV6CP
protocols.
2) Net interface with AT commands over serial ports: the modem provides
a 'net' interface that is activated with proprietary AT commands over a
serial port. IP addressing happens via either DHCP on that net interface
after the AT setup, or the IP/DNS details are queried via proprietary AT
commands.
3) Net interface with proprietary protocols: the modem provides a 'net'
interface that is activated via proprietary protocols (QMI, MBIM, CnS,
etc). IP addressing happens either via DHCP on the net interface after
proprietary protocol setup, or the IP/DNS details are queried via
proprietary protocol commands.
It's often possible to know what category a device fits into, but even
devices from the same manufacturer with *the same model number* can fall
into different categories, because the firmware is different, or because
the firmware can switch between these categories using special commands.
> I have tested a Ubuntu trusty kernel on my Ubuntu/precise system and
> compared the configs to get the stuff run on 3.18-rc2+.
> Beyond the "option" driver, I required usb_serial / usb_wwan to be
> activated and some more ("cde-ether" or sth. sound similiar...).
> ( Currently, I am not sitting (it's a Windows machine) in front of my
> machine, so I cannot send you my latest kernel-config. )
>
> As usually I looked into Documentation directory.
> So, my 1st question where do I get some informations in general on
> this topic - usb [1] or net subdirectory (seen from kernel-side)?
> I found a usb-serial kernel-doc [1].
> ( I have no Linux Git source so I cannot grep for patterns. )
None of those really have any information about WWAN specific setup, and
I fear that if documentation was added, it would be quickly out-of-date
because device manufacturers change things so frequently.
> The next mystery is what is network-manager doing in the background?
> I have seen that modem-manager is invoked, but as said I would like to
> understand the "internas" (means check the logs, turn on some
> debugging kernel-space/user-space, etc.).
NetworkManager uses ModemManager for all WWAN control, NM only handles
the configuration storage and IP addressing parts of the setup.
ModemManager handles modem hardware detection, capability detection,
WWAN registration and setup, signal strength reporting, network
connection initiation, and bearer IP addressing method determination.
If you want more information from ModemManager, you can run "mmcli
--help" or "mmcli --set-logging=debug".
> I am not sure but syncing with 3G network seems to take a while since
> I really can connect to the Internet.
What do you mean by "syncing"?
Dan
--
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 2/3] usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe
On Tue, 4 Nov 2014, Lu Baolu wrote:
> xhci: clear root port wake on bits if controller isn't wake-up capable
>
> When system is being suspended, if host device is not wakeup capable,
> xhci_suspend() needs to clear all root port wake on bits. Otherwise,
> some platforms may generate spurious wakeup, even if PCI PME# is dis-
> abled.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/usb/host/xhci.c | 42 ++
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 2a5d45b..cd57aae 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -35,6 +35,8 @@
> #define DRIVER_AUTHOR "Sarah Sharp"
> #define DRIVER_DESC "'eXtensible' Host Controller (xHC) Driver"
>
> +#define PORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
> +
> /* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared
> */
> static int link_quirk;
> module_param(link_quirk, int, S_IRUGO | S_IWUSR);
> @@ -851,6 +853,42 @@ static void xhci_clear_command_ring(struct xhci_hcd
> *xhci)
> xhci_set_cmd_ring_deq(xhci);
> }
>
> +static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
> +{
> + int port_index;
> + __le32 __iomem **port_array;
> + unsigned long flags;
> + u32 t1, t2;
> +
> + spin_lock_irqsave(&xhci->lock, flags);
> +
> + /* disble usb3 ports Wake bits*/
> + port_index = xhci->num_usb3_ports;
> + port_array = xhci->usb3_ports;
> + while (port_index--) {
> + t1 = readl(port_array[port_index]);
> + t2 = xhci_port_state_to_neutral(t1);
> + t2 &= ~PORT_WAKE_BITS;
> + t1 = xhci_port_state_to_neutral(t1);
> + if (t1 != t2)
> + writel(t2, port_array[port_index]);
> + }
> +
> + /* disble usb2 ports Wake bits*/
> + port_index = xhci->num_usb2_ports;
> + port_array = xhci->usb2_ports;
> + while (port_index--) {
> + t1 = readl(port_array[port_index]);
> + t2 = xhci_port_state_to_neutral(t1);
> + t2 &= ~PORT_WAKE_BITS;
> + t1 = xhci_port_state_to_neutral(t1);
> + if (t1 != t2)
> + writel(t2, port_array[port_index]);
> + }
> +
> + spin_unlock_irqrestore(&xhci->lock, flags);
> +}
> +
> /*
> * Stop HC (not bus-specific)
> *
> @@ -868,6 +906,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
> xhci->shared_hcd->state != HC_STATE_SUSPENDED)
> return -EINVAL;
>
> + /* Clear root port wake on bits if not wakeup capable. */
> + if (!device_may_wakeup(hcd->self.controller))
> + xhci_disable_port_wake_on_bits(xhci);
> +
> /* Don't poll the roothubs on bus suspend. */
> xhci_dbg(xhci, "%s: stopping port polling.\n", __func__);
> clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
This is better but still wrong. Remember, this same code gets called
for system suspend _and_ for runtime suspend. During runtime suspend,
wakeup is always supposed to be turned on, even if device_may_wakeup()
is false. That's because device_may_wakeup() refers only to system
suspend. What you need to test is the do_wakeup flag, which should be
passed into xhci_suspend() by xhci_pci_suspend() and
xhci_plat_suspend().
Another problem is in the patch description and the comments. If
device_may_wakeup() returns false, it doesn't mean the controller isn't
wakeup-capable -- it means the controller isn't _allowed_ to wake up
the system. Those are two different things.
Finally, the code in xhci_disable_port_wake_on_bits() looks a little
peculiar -- I'm not sure about all those calls to
xhci_port_state_to_neutral(). But I'm not an expert on that; Mathias
will have to advise on it.
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 v2 2/2] [usb] add support for ACPI identification to xhci-platform
On Tue, Nov 04, 2014 at 10:50:33AM -0600, Mark Langsdorf wrote:
> Provide the methods to let ACPI identify the need to use
> xhci-platform. Change the Kconfig files so the
> xhci-plat.o file is selectable during kernel config.
>
> Signed-off-by: Mark Langsdorf
> ---
> Changes from v1
> Renamed from "add support for APM X-Gene to xhci-platform"
> Removed changes to arm64/Kconfig
> Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
>
> drivers/usb/host/Kconfig | 7 ++-
> drivers/usb/host/xhci-plat.c | 11 +++
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 82800a7..060a2361 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -27,7 +27,12 @@ config USB_XHCI_HCD
> if USB_XHCI_HCD
>
> config USB_XHCI_PLATFORM
> - tristate
> + tristate "xHCI platform driver support"
> + --help--
> + Say 'Y' to enable the support for the xHCI host controller
> + as a platform device. Many ARM SoCs provide USB this way.
> +
> + If unsure, say 'Y'.
You really want a 'default Y' response here?
That's not good at all, what happens if I select this on a system
without such hardware?
>
> config USB_XHCI_MVEBU
> tristate "xHCI support for Marvell Armada 375/38x"
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 91c7557..3db47ea 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include "xhci.h"
> #include "xhci-mvebu.h"
> @@ -287,6 +288,15 @@ static const struct of_device_id usb_xhci_of_match[] = {
> MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
> #endif
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id usb_xhci_acpi_match[] = {
> + /* APM X-Gene USB Controller */
> + { "PNP0D10", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
> +#endif
That looks like a very "generic" PNP value, are you sure it is assigned
only to this specific device?
> +
> static struct platform_driver usb_xhci_driver = {
> .probe = xhci_plat_probe,
> .remove = xhci_plat_remove,
> @@ -294,6 +304,7 @@ static struct platform_driver usb_xhci_driver = {
> .name = "xhci-hcd",
> .pm = DEV_PM_OPS,
> .of_match_table = of_match_ptr(usb_xhci_of_match),
> + .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
Shouldn't the reworked driver core code handle this differently with the
ability to handle either OF or ACPI in the same driver?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [usb] make xhci platform driver use 64 bit or 32 bit DMA
On 11/03/2014 10:14 AM, Arnd Bergmann wrote: > On Monday 03 November 2014 09:15:51 Mark Salter wrote: >> On Thu, 2014-10-30 at 22:05 +0100, Arnd Bergmann wrote: >>> You should definitely make sure that this also works with DT, as >>> I don't think it's possible to support X-Gene with ACPI. I know >>> that Al Stone has experimented with it in the past, but he never >>> came back with any results, so I assume the experiment failed. My apologies; I am still remiss in making more patches public. Life interferes sometimes with my kernel development. I make no excuses for being farther behind in this than I have wanted. The experiment has not failed. The assumption is completely wrong. The git tree listed works on the X-Gene platform and it works on AMD Seattle; I have both running on my desk. Both DT and ACPI work, with the proper versions of the DT or the ACPI tables. I will post RFCs as soon as I can, but my work in progress is basically the same as the git tree mentioned below, based on slightly different starting points. >>> Note that the discussions about merging ACPI support on ARM64 >>> are based on the assumption that we'd only ever support SBSA-like >>> platforms, not something like X-Gene that looks more like an >>> embedded SoC. Your XHCI patches still obviously make sense for >>> other platforms, so that's not a show-stopper. >> >> But for some misconfiguration, the arm64 kernels in fedora arm >> koji would boot using ACPI on Mustang, the Foundation model, >> and AMD Seattle platforms. All very much a work in progress, >> but the tree from which the fedora patches are taken is the >> devel branch of: >> >> git.fedorahosted.org/git/kernel-arm64.git >> >> The configuration will be fixed this week and then you can >> just grab an arm64 fedora kernel and boot with acpi=force. Please note that I work directly with Mark Salter and that I have personally handed out this particular URL many times at either Linaro Connect and/or to individuals directly. It is not now nor has it ever been secret, at any time. > It's not as bad as I had feared, but it still does a lot of > the things that in previous discussions were said that ACPI > would avoid doing, and that were used as arguments against > just using DT on all arm64 servers: > > - The use of the device properties API that was introduced for > Intel's embedded devices for on-chip components directly > contradicts the "standardized firmware interfaces" argument > that certain people keep making. This certainly explains how > you plan to use the networking side, but I suspect it's not > what the ACPI proponents were looking for, or what the base > patch set is being advertised as. I do not understand this statement at all. One of the things that was added to the ACPI 5.1 specification was the _DSD method -- Device Specific Properties -- specifically so that device properties could be standardized. The API mentioned relies on the existence of _DSD for ACPI. Further, there are people from Linaro (who happen to work in the kernel and ACPI), the Linux community, as well as from Intel, ARM and even Microsoft working together to figure out ways to standardize the device properties being used in the ACPI Spec Working Group (ASWG) of the UEFI Forum; several of us are of course paying attention to, participating in, and incorporating the discussions on this kernel list and others. So what is not being standardized? From where I sit, as part of ASWG, Linaro, Red Hat, and some-time contributor to the Linux kernel, this whole device properties API was driven by the desire to have a standardized firmware interface. It even seems to be going a step further and trying to standardize how the kernel interacts with any firmware. > - Using custom drivers for hardware that is required by SBSA > (ahci, pci, ...) means you are contradicting the > Documentation/arm64/arm-acpi.txt document that is merged as > one of your early patches and that keeps getting posted as > the base of discussion for the inclusion of the base ACPI > support. I don't think you can have it both ways, saying that > SBSA is required and supporting hardware that doesn't do any > of it won't work. This is where I start the serious whinging On the one hand, I'm told "show the patches." Fine. Someone other than me happens to show patches for work in progress. Or, perhaps I show patches that work but are still proof of concept. It doesn't seem to matter which. The response then looks to me like I'm being told, "don't show patches that are not the absolute, final, irrefutable and irrevocable version." So which is it? The git tree mentioned is a work in progress. No one has ever claimed it was otherwise. This is exactly the same case as with the Linaro ACPI and kernel development trees. What I find incredibly frustrating is that I feel I am being told to submit the final form of patches for ACPI drivers, but those can ONLY be a work a progress until
Re: usbserial / ftdi_sio (+ others) bug?
On Tue, 4 Nov 2014 09:14:49 +0100 Johan Hovold wrote: > > 2. The chip responds with single correct character followed by a few > >hundred or so replies containing only the overrun status (no > > data) which are then converted to a bunch of binary zeroes by the > > ldisc because of the bug I mentioned earlier. After that the chip > > starts responding with proper data again and works until closed. > > Note that the only "bug" is that the application cannot disable the > overrun reporting, but why would you want that? The merits of doing so may be debatable, but if using the quotes around "bug" is supposed to indicate that it isn't one, I have to respectfully disagree. I know it is not the most important thing in the world and without the hardware fault I probably would not have seen it at all, but I would still call it a bug. > What's on the other side of the FTDI chip? Some kind of an optical receiver circuit (the link is optically isolated). On the other side of that is then the device that sends periodical data packets (a couple of times per second 17 bytes each) to the computer. The computer doesn't send anything i.e. the tx functionality of the chip is not used at all. > It still sounds like your hardware is broken, but at least you > seem to have found a work-around. Like I said, the hw is the real culprit here, there's no doubt about it. But I also doubt that it's just the individual chip in my device that has this issue. The device is practically brand new and while that is no guarantee that there won't be any faults, I find it much more likely that what I am seeing here is a quirk of the implementation and there are lots of these chips with the same issue out there. The real questions that remain are then; 1. is the chip real or counterfeit and how am I supposed to know it, 2. how much the driver can or even should try to accommodate the quirks of the hw, and 3. does the answer to #2 depend on the answer to #1. > Perhaps you can report it to the logging-device (?) manufacturer > or FTDI. Sure, if I can find someone that cares, which is doubtful. > What is the "lsusb -v" output for your device by the way. Bus 002 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice6.00 iManufacturer 1 FTDI iProduct2 FT232R USB UART iSerial 3 A400EJPK bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 90mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 2 FT232R USB UART Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered) -- 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 v3] usb: Remove references to non-existent PLAT_S5P symbol
On 04/11/14 00:24, Greg KH wrote:
> On Tue, Oct 07, 2014 at 11:12:07AM +0200, Sylwester Nawrocki wrote:
>> > The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
>> > ("ARM: SAMSUNG: Remove remaining legacy code"). There are still
>> > some references left, fix that by replacing them with ARCH_S5PV210.
>> >
>> > Fixes: d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
>> > Reported-by: Paul Bolle
>> > Acked-by: Jingoo Han
>> > Cc:[3.17+]
>
> This isn't a stable issue...
Sorry for disturbing then, let me go and read the documentation again.
--
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
[no subject]
I have two musb instances running in OTG. One instance is in device mode, the other in host mode. I enable remote wakeup for both ports (echo 1 > /sys/…/power/wakeup). On leaving suspend I see that the root-hub is resumed twice. I added a printk to hub_activate to see the device name and active-type + a WARN_ON(type == HUB_RESUME) and I see: |echo standby > /sys/power/state | PM: Syncing filesystems ... done. | PM: Preparing system for standby sleep | Freezing user space processes ... (elapsed 0.001 seconds) done. | Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. | PM: Entering standby sleep | Suspending console(s) (use no_console_suspend to debug) | PM: suspend of devices complete after 6.608 msecs | PM: late suspend of devices complete after 0.890 msecs | PM: noirq suspend of devices complete after 1.086 msecs | PM: Successfully put all powerdomains to target state | PM: Wakeup source UART | PM: noirq resume of devices complete after 16.454 msecs | PM: early resume of devices complete after 0.684 msecs | hub_activate(1024) usb1 4 | [ cut here ] | WARNING: CPU: 0 PID: 761 at drivers/usb/core/hub.c:1025 hub_activate+0x4a4/0x4dc() | CPU: 0 PID: 761 Comm: kworker/u2:2 Not tainted 3.14.23+ #287 | Workqueue: events_unbound async_run_entry_fn | [] (unwind_backtrace) from [] (show_stack+0x10/0x14) | [] (show_stack) from [] (warn_slowpath_common+0x68/0x88) | [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) | [] (warn_slowpath_null) from [] (hub_activate+0x4a4/0x4dc) | [] (hub_activate) from [] (hub_resume+0x14/0x1c) | [] (hub_resume) from [] (usb_resume_interface.isra.2+0x100/0x140) | [] (usb_resume_interface.isra.2) from [] (usb_resume_both+0x6c/0x13c) | [] (usb_resume_both) from [] (usb_resume+0x14/0x60) | [] (usb_resume) from [] (usb_dev_resume+0xc/0x10) | [] (usb_dev_resume) from [] (dpm_run_callback+0x34/0x70) | [] (dpm_run_callback) from [] (device_resume+0xb8/0x21c) | [] (device_resume) from [] (async_resume+0x18/0x44) | [] (async_resume) from [] (async_run_entry_fn+0x40/0x170) | [] (async_run_entry_fn) from [] (process_one_work+0x128/0x3b4) | [] (process_one_work) from [] (worker_thread+0x10c/0x364) | [] (worker_thread) from [] (kthread+0xbc/0xd8) | [] (kthread) from [] (ret_from_fork+0x14/0x3c) | ---[ end trace 005fc846a215a40c ]--- | PM: Finishing wakeup. | Restarting tasks ... | hub_activate(1024) usb1 4 | [ cut here ] | WARNING: CPU: 0 PID: 372 at drivers/usb/core/hub.c:1025 hub_activate+0x4a4/0x4dc() | CPU: 0 PID: 372 Comm: khubd Tainted: GW3.14.23+ #287 | [] (unwind_backtrace) from [] (show_stack+0x10/0x14) | [] (show_stack) from [] (warn_slowpath_common+0x68/0x88) | [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) | [] (warn_slowpath_null) from [] (hub_activate+0x4a4/0x4dc) | [] (hub_activate) from [] (hub_resume+0x14/0x1c) | [] (hub_resume) from [] (usb_resume_interface.isra.2+0x100/0x140) | [] (usb_resume_interface.isra.2) from [] (usb_resume_both+0x6c/0x13c) | [] (usb_resume_both) from [] (usb_runtime_resume+0x10/0x14) | [] (usb_runtime_resume) from [] (rpm_callback+0x9c/0xb8) | [] (rpm_callback) from [] (rpm_resume+0x330/0x560) | [] (rpm_resume) from [] (rpm_resume+0x1f8/0x560) | [] (rpm_resume) from [] (__pm_runtime_resume+0x18/0x40) | [] (__pm_runtime_resume) from [] (usb_autopm_get_interface+0x18/0x5c) | [] (usb_autopm_get_interface) from [] (hub_thread+0xf4/0x10c4) | [] (hub_thread) from [] (kthread+0xbc/0xd8) | [] (kthread) from [] (ret_from_fork+0x14/0x3c) | ---[ end trace 005fc846a215a40e ]--- | done. | [ cut here ] | WARNING: CPU: 0 PID: 372 at drivers/usb/core/urb.c:339 usb_submit_urb+0x494/0x4c8() | URB ddd59f80 submitted while active | CPU: 0 PID: 372 Comm: khubd Tainted: GW3.14.23+ #287 | [] (unwind_backtrace) from [] (show_stack+0x10/0x14) | [] (show_stack) from [] (warn_slowpath_common+0x68/0x88) | [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) | [] (warn_slowpath_fmt) from [] (usb_submit_urb+0x494/0x4c8) | [] (usb_submit_urb) from [] (hub_activate+0x224/0x4dc) | [] (hub_activate) from [] (hub_resume+0x14/0x1c) | [] (hub_resume) from [] (usb_resume_interface.isra.2+0x100/0x140) | [] (usb_resume_interface.isra.2) from [] (usb_resume_both+0x6c/0x13c) | [] (usb_resume_both) from [] (usb_runtime_resume+0x10/0x14) | [] (usb_runtime_resume) from [] (rpm_callback+0x9c/0xb8) | [] (rpm_callback) from [] (rpm_resume+0x330/0x560) | [] (rpm_resume) from [] (rpm_resume+0x1f8/0x560) | [] (rpm_resume) from [] (__pm_runtime_resume+0x18/0x40) | [] (__pm_runtime_resume) from [] (usb_autopm_get_interface+0x18/0x5c) | [] (usb_autopm_get_interface) from [] (hub_thread+0xf4/0x10c4) | [] (hub_thread) from [] (kthread+0xbc/0xd8) | [] (kthread) from [] (ret_from_fork+0x14/0x3c) | ---[ end trace 005fc846a215a40f ]--- | hub 1-0:1.0: activate --> -16 and I see the core resumes both hubs twice (I omitted usb2 here, the call
[PATCH V2] usb:host:xhci-plat: 64-bit dma addressing support
Use dma_addr_t to support 64-bit plaforms, which access beyond the default 32 bit address range. Signed-off-by: Bao Truong Signed-off-by: Feng Kan --- Changes: V2: fixed GKH's comment regarding not mark up the comment after code change. drivers/usb/host/xhci-plat.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 3d78b0c..f75764f 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -96,14 +96,18 @@ static int xhci_plat_probe(struct platform_device *pdev) return ret; } - /* Initialize dma_mask and coherent_dma_mask to 32-bits */ - ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); + /* +* Initialize dma_mask and coherent_dma_mask to valid DMA or bus +* address for the platform. +*/ + ret = dma_set_coherent_mask(&pdev->dev, + DMA_BIT_MASK(sizeof(dma_addr_t)*8)); if (ret) return ret; if (!pdev->dev.dma_mask) pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; else - dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)); + dma_set_mask(&pdev->dev, DMA_BIT_MASK(sizeof(dma_addr_t)*8)); hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev)); if (!hcd) -- 1.9.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: your mail
On Tue, 4 Nov 2014, Sebastian Andrzej Siewior wrote: > I have two musb instances running in OTG. One instance is in device mode, > the other in host mode. I enable remote wakeup for both ports > (echo 1 > /sys/…/power/wakeup). On leaving suspend I see that the root-hub > is resumed twice. I added a printk to hub_activate to see the device > name and active-type + a WARN_ON(type == HUB_RESUME) and I see: > > |echo standby > /sys/power/state > | PM: Syncing filesystems ... done. > | PM: Preparing system for standby sleep > | Freezing user space processes ... (elapsed 0.001 seconds) done. > | Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. > | PM: Entering standby sleep > | Suspending console(s) (use no_console_suspend to debug) > | PM: suspend of devices complete after 6.608 msecs > | PM: late suspend of devices complete after 0.890 msecs > | PM: noirq suspend of devices complete after 1.086 msecs > | PM: Successfully put all powerdomains to target state > | PM: Wakeup source UART > | PM: noirq resume of devices complete after 16.454 msecs > | PM: early resume of devices complete after 0.684 msecs > | hub_activate(1024) usb1 4 > | [ cut here ] > | WARNING: CPU: 0 PID: 761 at drivers/usb/core/hub.c:1025 > hub_activate+0x4a4/0x4dc() > | CPU: 0 PID: 761 Comm: kworker/u2:2 Not tainted 3.14.23+ #287 > | Workqueue: events_unbound async_run_entry_fn > | [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > | [] (show_stack) from [] (warn_slowpath_common+0x68/0x88) > | [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x1c/0x24) > | [] (warn_slowpath_null) from [] > (hub_activate+0x4a4/0x4dc) > | [] (hub_activate) from [] (hub_resume+0x14/0x1c) > | [] (hub_resume) from [] > (usb_resume_interface.isra.2+0x100/0x140) > | [] (usb_resume_interface.isra.2) from [] > (usb_resume_both+0x6c/0x13c) > | [] (usb_resume_both) from [] (usb_resume+0x14/0x60) > | [] (usb_resume) from [] (usb_dev_resume+0xc/0x10) > | [] (usb_dev_resume) from [] (dpm_run_callback+0x34/0x70) > | [] (dpm_run_callback) from [] (device_resume+0xb8/0x21c) > | [] (device_resume) from [] (async_resume+0x18/0x44) > | [] (async_resume) from [] > (async_run_entry_fn+0x40/0x170) > | [] (async_run_entry_fn) from [] > (process_one_work+0x128/0x3b4) > | [] (process_one_work) from [] > (worker_thread+0x10c/0x364) > | [] (worker_thread) from [] (kthread+0xbc/0xd8) > | [] (kthread) from [] (ret_from_fork+0x14/0x3c) > | ---[ end trace 005fc846a215a40c ]--- > | PM: Finishing wakeup. > | Restarting tasks ... > | hub_activate(1024) usb1 4 > | [ cut here ] > | WARNING: CPU: 0 PID: 372 at drivers/usb/core/hub.c:1025 > hub_activate+0x4a4/0x4dc() > | CPU: 0 PID: 372 Comm: khubd Tainted: GW3.14.23+ #287 > | [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > | [] (show_stack) from [] (warn_slowpath_common+0x68/0x88) > | [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x1c/0x24) > | [] (warn_slowpath_null) from [] > (hub_activate+0x4a4/0x4dc) > | [] (hub_activate) from [] (hub_resume+0x14/0x1c) > | [] (hub_resume) from [] > (usb_resume_interface.isra.2+0x100/0x140) > | [] (usb_resume_interface.isra.2) from [] > (usb_resume_both+0x6c/0x13c) > | [] (usb_resume_both) from [] > (usb_runtime_resume+0x10/0x14) > | [] (usb_runtime_resume) from [] (rpm_callback+0x9c/0xb8) > | [] (rpm_callback) from [] (rpm_resume+0x330/0x560) > | [] (rpm_resume) from [] (rpm_resume+0x1f8/0x560) > | [] (rpm_resume) from [] (__pm_runtime_resume+0x18/0x40) > | [] (__pm_runtime_resume) from [] > (usb_autopm_get_interface+0x18/0x5c) > | [] (usb_autopm_get_interface) from [] > (hub_thread+0xf4/0x10c4) > | [] (hub_thread) from [] (kthread+0xbc/0xd8) > | [] (kthread) from [] (ret_from_fork+0x14/0x3c) > | ---[ end trace 005fc846a215a40e ]--- > | done. > | [ cut here ] > | WARNING: CPU: 0 PID: 372 at drivers/usb/core/urb.c:339 > usb_submit_urb+0x494/0x4c8() > | URB ddd59f80 submitted while active > | CPU: 0 PID: 372 Comm: khubd Tainted: GW3.14.23+ #287 > | [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > | [] (show_stack) from [] (warn_slowpath_common+0x68/0x88) > | [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x30/0x40) > | [] (warn_slowpath_fmt) from [] > (usb_submit_urb+0x494/0x4c8) > | [] (usb_submit_urb) from [] (hub_activate+0x224/0x4dc) > | [] (hub_activate) from [] (hub_resume+0x14/0x1c) > | [] (hub_resume) from [] > (usb_resume_interface.isra.2+0x100/0x140) > | [] (usb_resume_interface.isra.2) from [] > (usb_resume_both+0x6c/0x13c) > | [] (usb_resume_both) from [] > (usb_runtime_resume+0x10/0x14) > | [] (usb_runtime_resume) from [] (rpm_callback+0x9c/0xb8) > | [] (rpm_callback) from [] (rpm_resume+0x330/0x560) > | [] (rpm_resume) from [] (rpm_resume+0x1f8/0x560) > | [] (rpm_resume) from [] (__pm_runtime_resume+0x18/0x40) > | [] (__pm_runtime_resume) from [] > (usb_autopm_get_interface+0x18/0x5c) > | [] (usb_autopm_get_interface
Re: [PATCH v3] usb: Remove references to non-existent PLAT_S5P symbol
On Tue, 2014-11-04 at 19:33 +0100, Sylwester Nawrocki wrote: > On 04/11/14 00:24, Greg KH wrote: > > This isn't a stable issue... > > Sorry for disturbing then, let me go and read the documentation again. If I remember correctly, I asked Sylwester to mark this for stable. So it's me that should be educated here. Why is a patch that allows the users of ARCH_S5PV210 to set USB_EHCI_EXYNOS or USB_OHCI_EXYNOS - which they apparently need - for a v3.17.y kernel, not a stable issue? Paul Bolle -- 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 v3] usb: Remove references to non-existent PLAT_S5P symbol
On Tue, Nov 04, 2014 at 08:21:04PM +0100, Paul Bolle wrote: > On Tue, 2014-11-04 at 19:33 +0100, Sylwester Nawrocki wrote: > > On 04/11/14 00:24, Greg KH wrote: > > > This isn't a stable issue... > > > > Sorry for disturbing then, let me go and read the documentation again. > > If I remember correctly, I asked Sylwester to mark this for stable. So > it's me that should be educated here. > > Why is a patch that allows the users of ARCH_S5PV210 to set > USB_EHCI_EXYNOS or USB_OHCI_EXYNOS - which they apparently need - for a > v3.17.y kernel, not a stable issue? As it's something that no one seemed to ever need before (i.e. it's not a regression fix), but it would be a "new feature", I don't think it's really a stable fix. But feel free to convince me otherwise :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb: Remove references to non-existent PLAT_S5P symbol
On Tue, 2014-11-04 at 11:42 -0800, Greg KH wrote: > As it's something that no one seemed to ever need before (i.e. it's not > a regression fix), but it would be a "new feature", I don't think it's > really a stable fix. > > But feel free to convince me otherwise :) Sylwester, was I right in thinking that users of PLAT_S5P, who could set USB_EHCI_EXYNOS or USB_OHCI_EXYNOS pre v3.17, got, well, transferred to ARCH_S5PV210 and lost the ability to set one of those symbols in v3.17? Paul Bolle -- 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: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on arndale platform
On Tue, Nov 04, 2014 at 11:23:06AM +0100, Stam, Michel [FINT] wrote:
> Hello Riku,
>
> >Fixing a bug (ethtool support) must not cause breakage elsewhere (in
> this case on arndale). This is now a regression of functionality from
> 3.17.
> >
> >I think it would better to revert the change now and with less hurry
> introduce a ethtool fix that doesn't break arndale.
>
> I don't fully agree here;
> I would like to point out that this commit is a revert itself. Fixing
> the armdale will then cause breakage in other implementations, such as
> ours. Blankly reverting breaks other peoples' implementations.
>
> The PHY reset is the thing that breaks ethtool support, so any fix that
> appeases all would have to take existing PHY state into account.
>
> I'm not an expert on the ASIX driver, nor the MII, but I think this is
> the cause;
> drivers/net/usb/asix_devices.c:
>361 asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
> BMCR_RESET);
>362 asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
>363 ADVERTISE_ALL | ADVERTISE_CSMA);
>364 mii_nway_restart(&dev->mii);
>
> I would think that the ADVERTISE_ALL is the cause here, as it will reset
> the MII back to default, thus overriding ethtool settings.
> Would an:
> Int reg;
> reg = asix_mdio_read(dev->net,dev->mii.phy_id,MII_ADVERTISE);
>
> prior to the offending lines, and then;
>
>362 asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
>363 reg);
>
> solve the problem for you guys?
If I revert the patch in question and add this in:
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -299,6 +299,7 @@ static int ax88772_reset(struct usbnet *dev)
{
struct asix_data *data = (struct asix_data *)&dev->data;
int ret, embd_phy;
+ int reg;
u16 rx_ctl;
ret = asix_write_gpio(dev,
@@ -359,8 +360,10 @@ static int ax88772_reset(struct usbnet *dev)
msleep(150);
asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR, BMCR_RESET);
- asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
- ADVERTISE_ALL | ADVERTISE_CSMA);
+ reg = asix_mdio_read(dev->net, dev->mii.phy_id, MII_ADVERTISE);
+ if (!reg)
+ reg = ADVERTISE_ALL | ADVERTISE_CSMA;
+ asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE, reg);
mii_nway_restart(&dev->mii);
ret = asix_write_medium_mode(dev, AX88772_MEDIUM_DEFAULT);
Then things work on Arndale for me. Does that work for you?
Whether that is a sensible fix I don't know however.
>
> Mind, maybe the read function should take into account the reset value
> of the MII, and set it to ADVERTISE_ALL | ADVERTISE_CSMA. I don't have
> any documention here at the moment.
Yeah I also have no documentation.
Thanks,
Charles
>
> Is anyone able to confirm my suspicions?
>
> Kind regards,
>
> Michel Stam
> -Original Message-
> From: Riku Voipio [mailto:riku.voi...@iki.fi]
> Sent: Tuesday, November 04, 2014 10:44 AM
> To: Stam, Michel [FINT]
> Cc: Riku Voipio; da...@davemloft.net; linux-usb@vger.kernel.org;
> net...@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-samsung-...@vger.kernel.org; ckee...@opensource.wolfsonmicro.com
> Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net
> on arndale platform
>
> On Tue, Nov 04, 2014 at 09:19:26AM +0100, Stam, Michel [FINT] wrote:
> > Interesting, as the commit itself is a revert from a kernel back to
> > 2.6 somewhere. The problem I had is related to the PHY being reset on
> > interface-up, can you confirm that you require this?
>
> I can't confirm what exactly is needed on arndale. I'm neither expert in
> USB or ethernet. However, I can confirm that without the PHY reset,
> networking doesn't work on arndale.
>
> I now see someone else has the same problem, adding Charles to CC.
>
> http://www.spinics.net/lists/linux-usb/msg116656.html
>
> > Reverting this
> > breaks ethtool support in turn.
>
> Fixing a bug (ethtool support) must not cause breakage elsewhere (in
> this case on arndale). This is now a regression of functionality from
> 3.17.
>
> I think it would better to revert the change now and with less hurry
> introduce a ethtool fix that doesn't break arndale.
>
> > Kind regards,
> >
> > Michel Stam
> >
> > -Original Message-
> > From: Riku Voipio [mailto:riku.voi...@iki.fi]
> > Sent: Tuesday, November 04, 2014 8:23 AM
> > To: da...@davemloft.net; Stam, Michel [FINT]
> > Cc: linux-usb@vger.kernel.org; net...@vger.kernel.org;
> > linux-ker...@vger.kernel.org; linux-samsung-...@vger.kernel.org
> > Subject: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on
>
> > arndale platform
> >
> > Hi,
> >
> > With 3.18-rc3, asix on arndale (samsung exynos 5250 based board),
> > fails to work. Interface is initialized but network traffic seem not
> > to pass through. With kernel IP config the result looks like:
Re: [PATCH RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding
On Fri, Oct 31, 2014 at 9:41 AM, Andrew Bresticker
wrote:
> On Fri, Oct 31, 2014 at 4:32 AM, Thierry Reding
> wrote:
>> On Thu, Oct 30, 2014 at 10:26:47AM -0700, Andrew Bresticker wrote:
>>> On Thu, Oct 30, 2014 at 10:24 AM, Thierry Reding
>>> wrote:
>>> > On Thu, Oct 30, 2014 at 10:19:21AM -0700, Andrew Bresticker wrote:
>>> >> On Thu, Oct 30, 2014 at 6:55 AM, Thierry Reding
>>> >> wrote:
>>> >> > On Wed, Oct 29, 2014 at 09:37:14AM -0700, Andrew Bresticker wrote:
>>> >> >> On Wed, Oct 29, 2014 at 2:43 AM, Thierry Reding
>>> >> >> wrote:
>>> >> >> > On Tue, Oct 28, 2014 at 03:27:50PM -0700, Andrew Bresticker wrote:
>>> >> >> > [...]
>>> >> >> >> diff --git
>>> >> >> >> a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
>>> >> >> >>
>>> >> >> >> b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
>>> >> >> > [...]
>>> >> >> >> +Optional properties:
>>> >> >> >> +---
>>> >> >> >> +- vbus-{0,1,2}-supply: VBUS regulator for the corresponding UTMI
>>> >> >> >> pad.
>>> >> >> >> +- vddio-hsic-supply: VDDIO regulator for the HSIC pads.
>>> >> >> >> +- nvidia,usb3-port-{0,1}-lane: PCIe/SATA lane to which the
>>> >> >> >> corresponding USB3
>>> >> >> >> + port is mapped. See
>>> >> >> >> for the list
>>> >> >> >> + of valid values.
>>> >> >> >
>>> >> >> > I dislike how we now need to provide a list of all pins in the
>>> >> >> > header
>>> >> >> > file, where previously we used strings for this. This could become
>>> >> >> > very
>>> >> >> > ugly if the set of pins changes in future generations of this IP
>>> >> >> > block.
>>> >> >> >
>>> >> >> > Could we instead derive this from the pinmux nodes? For example you
>>> >> >> > have
>>> >> >> > this in the example below:
>>> >> >> >
>>> >> >> > usb3p0 {
>>> >> >> > nvidia,lanes = "pcie-0";
>>> >> >> > ...
>>> >> >> > };
>>> >> >> >
>>> >> >> > Perhaps what we need is to either key off the node name or add
>>> >> >> > another
>>> >> >> > property, such as:
>>> >> >> >
>>> >> >> > nvidia,usb3-port = <0>;
>>> >> >> >
>>> >> >> > This would match the nvidia,usb2-port property that you've added
>>> >> >> > below.
>>> >> >>
>>> >> >> That is actually how I described the USB3 port to SS lane mapping
>>> >> >> originally, but in review of an earlier version of this series,
>>> >> >> Stephen suggested that I make it a separate, not pinconfig property
>>> >> >> since it wasn't a value written directly to the hardware. I'm fine
>>> >> >> with changing it back as the pinconfig property makes more sense to me
>>> >> >> as well.
>>> >> >
>>> >> > Hmm... I had considered it a mux option of the specific lane. If the
>>> >> > function is usb3, it'd still need to be muxed to one of the ports. So
>>> >> > it's additional information associated with the usb3 function.
>>> >> >
>>> >> > I did look through the driver changes and can't really make out which
>>> >> > part of the code actually performs this assignment. Can you point me to
>>> >> > it?
>>> >>
>>> >> There's not really an assignment. The property is used to map between
>>> >> a lane (e.g. PCIe-0 or SATA) and the USB3.0 port it's mapped to. For
>>> >> an example of where it's used, take a look at usb3_phy_power_on().
>>> >> There are certain per-lane registers which need to be programmed in
>>> >> addition to the per-USB3.0 port pad registers. This mapping is used
>>> >> to determine which lane needs to be programmed.
>>> >
>>> > Are you saying the mapping of lane to USB port is fixed? That is, PCIe-0
>>> > lane is always used for USB port X and SATA always for USB port Y?
>>>
>>> No, sorry if that was unclear, it's not fixed - it's a board specific
>>> property.
>>
>> Okay, but there's no register that contains the mapping of the port to a
>> lane, similar to what's done for the functions, right?
>
> Correct.
>
>> I mean the driver only uses the lane to find out which register to write.
>> Doesn't that imply that two lanes (or more) could be mapped to the same
>> USB 3.0 port?
>
> I guess? Not sure how that would work in hardware to have two
> SuperSpeed lanes wired up to a single port.
>
>> I'm not sure I'm being clear here, so let me try another way. In order
>> to establish a mapping between USB port and lane, I would've expected
>> one of the following to happen:
>>
>> - A value derived from the lane number is written to a register
>> belonging to a given port.
>>
>> - A value derived from the port number is written to a register
>> belonging to a given lane.
>>
>> I can't see the code do either of the above, which to me implies that
>> there's a fixed mapping between lanes and ports. What am I missing?
>
> It's fixed in that it's not a software-modifiable property. It's
> describing an electrical connection between lane and port. For
> example, it's possible that one board has PCIe lane 1 wired up to
> SuperSpeed port 1 and on another board
Re: [PATCH v1 1/3] usb: phy: device-tree documentation for gpio-vbus
Philipp Zabel writes:
> Hi Robert,
>
> On Sun, Nov 2, 2014 at 7:11 PM, Robert Jarzmik wrote:
> Maybe duplicate the comment from the driver here how his is about
> B peripheral only devices
Yeah sure, for v2.
>> +Required properties:
>> +- compatible : should be "generic,phy-gpio-vbus"
>
> I'm not sure about the compatible value. I have not seen the "generic,"
> vendor prefix, and all the other generic gpio-something bindings don't
> use any prefix: "gpio-gate-clock", "gpio-leds", "gpio-beeper",
> "pps-gpio", etc.
Okay, so we'll probably end up on "phy-gpio-vbus" then.
>> +- #phy-cells : from the generic PHY bindings, must be 1.
>> +- gpios : set of 2 gpio properties (see gpio.txt for gpio properties
>> format)
>> + first gpio is required, it's the VBus sensing input gpio
>> + second gpio is optional, it's the D+ pullup controlling output
>> + gpio
>> +
>> +Optional properties:
>> +- wakeup : boolean, if true the VBus gpio will wakeup the platform
>
> The vbus_draw regulator should be part of this binding, I think.
Indeed. It should be optional, right ? Schedules for v2.
>> +Example:
>> + usb2phy : gpio-vbus@13 {
>> + compatible = "generic,phy-gpio-vbus";
>> + gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
>> + wakeup;
>
> This on the other hand might be too generic.
> I'd like to see just wakeup used here, but the other bindings prefix
> "linux," (or "gpio-key,").
If I write this, would you change to better suit you ?
usb2phy : gpio-vbus@13 {
compatible = "phy-gpio-vbus";
regulator-vbus: regulator@0 {
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-always-on;
};
vbus-gpio = <&gpio 13 GPIO_ACTIVE_LOW>;
wakeup;
};
Cheers.
--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
USB Data toggle differences between USB 2 and USB 3?
Hello linux-usb! I am the administrator of SANE (Scanner Access Now Easy), which provides scanner drivers for over 1000 models of scanner on multiple platforms, including Linux. Many of those scanners are USB, and we have had an increase in bug reports in some of those as of late. So, I have done some initial investigation, and need some help. Generally, we use a wrapper around libusb for our access, and don't have to worry much about kernel-level details. However, we have a number of reports where our code works perfectly when a scanner is attached to a usb port controlled by ehci_hcd, but fails when that same port is controlled by xhci_hcd. The libusb, sane, and kernel versions are varied, though the behaviour is consistent. This seems at first glance to be a Data0/1 toggle problem. Specifically, the sane protocol has a detection step, followed by a separate 'actually do something' step. The former involves many distinct drivers each trying in turn to open, communicate with, and close any attached scanners they recognise. The latter is a single driver reopening a single scanner, and doing more extensive communications before closing again. Under USB 2, this pattern works, though the second step sometimes requires retries on the first command sent, because the Data toggle is confused. Attempts to use that same code on USB 3 (including the retries) fail. Modifications to the initial step to either: 1. stop closing the descriptor, or 2. make the number of commands even, seem to correct the problem for at least one iteration of the process. So, my questions- What is different about the handling of the Data toggle between the implementation of USB 2 and 3, and is there something different that we should be doing from user space to prevent this issue? I will be happy to provide additional debugging info, just let me know. Thanks for any insights- allan -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand" -- 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
[Regression][v3.17][v3.18] USB: Fix persist resume of some SS USB devices
Hello Pratyush, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit a40178b2fa6ad87670fb1e5fa4024db00c149629 Author: Pratyush Anand Date: Fri Jul 18 12:37:10 2014 +0530 USB: Fix persist resume of some SS USB devices The regression was introduced as of v3.17-rc1. The regression still exists in the 3.18-rc3 mainline kernel, and has made it's way into the stable kernels. I was hoping to get your feedback, since you are the patch author. Do you think gathering any additional data will help diagnose this issue, or would it be best to submit a revert request? Thanks, Joe [0] http://pad.lv/1384041 -- 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] renesas_usbhs: fix platform init error message
There is a typo ("prove" instead of "probe") in the error message printed when
the platform initialization fails. Replace that word with more fitting "init".
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'usb-linus' branch of Greg KH's 'usb.git' repo.
Changes in varsion 2:
- refreshed the patch.
drivers/usb/renesas_usbhs/common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: usb/drivers/usb/renesas_usbhs/common.c
===
--- usb.orig/drivers/usb/renesas_usbhs/common.c
+++ usb/drivers/usb/renesas_usbhs/common.c
@@ -615,7 +615,7 @@ static int usbhs_probe(struct platform_d
*/
ret = usbhs_platform_call(priv, hardware_init, pdev);
if (ret < 0) {
- dev_err(&pdev->dev, "platform prove failed.\n");
+ dev_err(&pdev->dev, "platform init failed.\n");
goto probe_end_mod_exit;
}
--
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] renesas_usbhs: fix platform init error message
On Wed, Nov 05, 2014 at 01:48:48AM +0300, Sergei Shtylyov wrote:
> There is a typo ("prove" instead of "probe") in the error message printed when
> the platform initialization fails. Replace that word with more fitting "init".
>
> Signed-off-by: Sergei Shtylyov
this actually goes through me, I'll take it in a bit.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] renesas_usbhs: fix platform init error message
Hello.
On 11/05/2014 01:53 AM, Felipe Balbi wrote:
There is a typo ("prove" instead of "probe") in the error message printed when
the platform initialization fails. Replace that word with more fitting "init".
Signed-off-by: Sergei Shtylyov
this actually goes through me, I'll take it in a bit.
Er, OK. Could you update MAINTAINERS?
WBR, Sergei
--
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] renesas_usbhs: fix platform init error message
Hi,
On Wed, Nov 05, 2014 at 01:55:17AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 11/05/2014 01:53 AM, Felipe Balbi wrote:
>
> >>There is a typo ("prove" instead of "probe") in the error message printed
> >>when
> >>the platform initialization fails. Replace that word with more fitting
> >>"init".
>
> >>Signed-off-by: Sergei Shtylyov
>
> >this actually goes through me, I'll take it in a bit.
>
>Er, OK. Could you update MAINTAINERS?
there is no entry for renesas driver in MAINTAINERS.
Shimoda-san, care to send a patch adding yourself or Morimoto-san as
maintainers for Renesas driver and pointing to my tree in kernel.org ?
Thank you
--
balbi
signature.asc
Description: Digital signature
[PATCH 08/10] fotg210: Remove duplicate ehci-dbgp declarations
Now that ehci-dbgp has its own header, use it rather than duplicating
the declarations, etc.
Signed-off-by: Chris Rorvick
---
drivers/usb/host/fotg210.h | 40 ++--
1 file changed, 2 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/host/fotg210.h b/drivers/usb/host/fotg210.h
index c2e5134..975d9bb 100644
--- a/drivers/usb/host/fotg210.h
+++ b/drivers/usb/host/fotg210.h
@@ -1,6 +1,8 @@
#ifndef __LINUX_FOTG210_H
#define __LINUX_FOTG210_H
+#include
+
/* definitions used for the EHCI driver */
/*
@@ -304,44 +306,6 @@ struct fotg210_dbg_port {
u32 address;
};
-#ifdef CONFIG_EARLY_PRINTK_DBGP
-#include
-extern int __init early_dbgp_init(char *s);
-extern struct console early_dbgp_console;
-#endif /* CONFIG_EARLY_PRINTK_DBGP */
-
-struct usb_hcd;
-
-#ifdef CONFIG_XEN_DOM0
-extern int xen_dbgp_reset_prep(struct usb_hcd *);
-extern int xen_dbgp_external_startup(struct usb_hcd *);
-#else
-static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
-{
- return 1; /* Shouldn't this be 0? */
-}
-
-static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
-{
- return -1;
-}
-#endif
-
-#ifdef CONFIG_EARLY_PRINTK_DBGP
-/* Call backs from fotg210 host driver to fotg210 debug driver */
-extern int dbgp_external_startup(struct usb_hcd *);
-extern int dbgp_reset_prep(struct usb_hcd *hcd);
-#else
-static inline int dbgp_reset_prep(struct usb_hcd *hcd)
-{
- return xen_dbgp_reset_prep(hcd);
-}
-static inline int dbgp_external_startup(struct usb_hcd *hcd)
-{
- return xen_dbgp_external_startup(hcd);
-}
-#endif
-
/*-*/
#defineQTD_NEXT(fotg210, dma) cpu_to_hc32(fotg210, (u32)dma)
--
1.9.3
--
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 10/10] usb: Remove __init from early_dbgp_init() prototype
Specifying these attributes in both the prototype and the function
definition is unnecessary and could cause confusion or bugs if they are
inconsistent. As such, __init should only be specified at the function
definition.
Keith Owens suggested this as a janitorial task on LKML several years
ago:
https://lkml.org/lkml/2006/1/14/305
Signed-off-by: Chris Rorvick
---
include/linux/usb/ehci-dbgp.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/usb/ehci-dbgp.h b/include/linux/usb/ehci-dbgp.h
index 796c1cd..7344d9e 100644
--- a/include/linux/usb/ehci-dbgp.h
+++ b/include/linux/usb/ehci-dbgp.h
@@ -43,8 +43,7 @@ struct ehci_dbg_port {
};
#ifdef CONFIG_EARLY_PRINTK_DBGP
-#include
-extern int __init early_dbgp_init(char *s);
+extern int early_dbgp_init(char *s);
extern struct console early_dbgp_console;
#endif /* CONFIG_EARLY_PRINTK_DBGP */
--
1.9.3
--
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 06/10] fotg210: Make Xen notification consistent with EHCI
If CONFIG_XEN_DOM0 is enabled, the ehci-dbgp driver notifies Xen of
controller reset events via xen_dbgp_reset_prep() and
xen_dbgp_external_startup() (via calls to xen_dbgp_op().) Otherwise
defines them as no-ops to disable this logic.
The fotg210 driver copies much of the dbgp code from ehci_def.h, but it
unconditionally defines the Xen hooks as no-ops, effectively disabling
these notifications when CONFIG_EARLY_PRINTK_DBGP is disabled. When
enabled, though, notifying Xen is dependent on CONFIG_XEN_DOM0 due to
fotg210 leveraging the ehci-dbgp driver.
The following table compares the implementations of xen_dbgp_reset_prep()
and xen_dbgp_external_startup() in the ehci-dbgp and fotg210 drivers
under the relevant configurations:
EARLY_PRINTK_DBGP? XEN_DOM0? ehci-dbgp fotg210
-- - - -
n n no-op no-op
n y xen_dbgp_op() no-op
y n no-op no-op
y y xen_dbgp_op() xen_dbgp_op()
This suggests that fotg210 is, at best, indifferent to whether Xen is
notified of these events. Make fotg210 consistent with ehci-dbgp as a
step towards consolidating this code duplication.
Signed-off-by: Chris Rorvick
---
drivers/usb/host/fotg210.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/host/fotg210.h b/drivers/usb/host/fotg210.h
index ac6cd1b..98c9670 100644
--- a/drivers/usb/host/fotg210.h
+++ b/drivers/usb/host/fotg210.h
@@ -326,6 +326,10 @@ extern struct console early_dbgp_console;
struct usb_hcd;
+#ifdef CONFIG_XEN_DOM0
+extern int xen_dbgp_reset_prep(struct usb_hcd *);
+extern int xen_dbgp_external_startup(struct usb_hcd *);
+#else
static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
{
return 1; /* Shouldn't this be 0? */
@@ -335,6 +339,7 @@ static inline int xen_dbgp_external_startup(struct usb_hcd
*hcd)
{
return -1;
}
+#endif
#ifdef CONFIG_EARLY_PRINTK_DBGP
/* Call backs from fotg210 host driver to fotg210 debug driver */
--
1.9.3
--
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 05/10] fusbh200: Use ehci_dbg_port struct
The FUSBH200 debug port has a EHCI-compatible register layout so there
is no need to define a custom struct.
Signed-off-by: Chris Rorvick
---
drivers/usb/host/fusbh200.h | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/usb/host/fusbh200.h b/drivers/usb/host/fusbh200.h
index 47aecfc..d6e5b3d 100644
--- a/drivers/usb/host/fusbh200.h
+++ b/drivers/usb/host/fusbh200.h
@@ -86,7 +86,7 @@ struct fusbh200_hcd { /* one per controller */
/* glue to PCI and HCD framework */
struct fusbh200_caps __iomem *caps;
struct fusbh200_regs __iomem *regs;
- struct fusbh200_dbg_port __iomem *debug;
+ struct ehci_dbg_port __iomem *debug;
__u32 hcs_params; /* cached register copy */
spinlock_t lock;
@@ -287,17 +287,6 @@ struct fusbh200_regs {
#define BMIER_VBUS_ERR_EN (1<<0)
};
-/* Appendix C, Debug port ... intended for use with special "debug devices"
- * that can help if there's no serial console. (nonstandard enumeration.)
- */
-struct fusbh200_dbg_port {
- u32 control;
- u32 pids;
- u32 data03;
- u32 data47;
- u32 address;
-};
-
/*-*/
#defineQTD_NEXT(fusbh200, dma) cpu_to_hc32(fusbh200, (u32)dma)
--
1.9.3
--
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 09/10] fotg210: Use ehci_dbg_port struct
The FUSBH200 debug port has a EHCI-compatible register layout so there
is no need to define a custom struct.
Signed-off-by: Chris Rorvick
---
drivers/usb/host/fotg210.h | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/usb/host/fotg210.h b/drivers/usb/host/fotg210.h
index 975d9bb..3bad178 100644
--- a/drivers/usb/host/fotg210.h
+++ b/drivers/usb/host/fotg210.h
@@ -86,7 +86,7 @@ struct fotg210_hcd { /* one per controller */
/* glue to PCI and HCD framework */
struct fotg210_caps __iomem *caps;
struct fotg210_regs __iomem *regs;
- struct fotg210_dbg_port __iomem *debug;
+ struct ehci_dbg_port __iomem *debug;
__u32 hcs_params; /* cached register copy */
spinlock_t lock;
@@ -295,17 +295,6 @@ struct fotg210_regs {
#define GMIR_MDEV_INT (1 << 0)
};
-/* Appendix C, Debug port ... intended for use with special "debug devices"
- * that can help if there's no serial console. (nonstandard enumeration.)
- */
-struct fotg210_dbg_port {
- u32 control;
- u32 pids;
- u32 data03;
- u32 data47;
- u32 address;
-};
-
/*-*/
#defineQTD_NEXT(fotg210, dma) cpu_to_hc32(fotg210, (u32)dma)
--
1.9.3
--
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 07/10] fotg210: Remove superfluous macro definitions
The fotg210_dbg_port struct is a copy of the ehci_dbg_port definition
in the header. Embedded in this definition are
a number of macros which came along for the ride. These macros are not
used in the fotg210 driver and will conflict those in the new
header.
Signed-off-by: Chris Rorvick
---
drivers/usb/host/fotg210.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/usb/host/fotg210.h b/drivers/usb/host/fotg210.h
index 98c9670..c2e5134 100644
--- a/drivers/usb/host/fotg210.h
+++ b/drivers/usb/host/fotg210.h
@@ -298,24 +298,10 @@ struct fotg210_regs {
*/
struct fotg210_dbg_port {
u32 control;
-#define DBGP_OWNER (1<<30)
-#define DBGP_ENABLED (1<<28)
-#define DBGP_DONE (1<<16)
-#define DBGP_INUSE (1<<10)
-#define DBGP_ERRCODE(x)(((x)>>7)&0x07)
-# define DBGP_ERR_BAD 1
-# define DBGP_ERR_SIGNAL 2
-#define DBGP_ERROR (1<<6)
-#define DBGP_GO(1<<5)
-#define DBGP_OUT (1<<4)
-#define DBGP_LEN(x)(((x)>>0)&0x0f)
u32 pids;
-#define DBGP_PID_GET(x)(((x)>>16)&0xff)
-#define DBGP_PID_SET(data, tok)(((data)<<8)|(tok))
u32 data03;
u32 data47;
u32 address;
-#define DBGP_EPADDR(dev, ep) (((dev)<<8)|(ep))
};
#ifdef CONFIG_EARLY_PRINTK_DBGP
--
1.9.3
--
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 00/10] Create separate header for ehci-dbgp driver
The FUSBH200 and FOTG210 are not EHCI-compatible and require standalone drivers. See discussion at: http://comments.gmane.org/gmane.linux.usb.general/84169 But these controllers do implement an EHCI-compatible debug port and therefore leverage the ehci-dbgp driver. Rather than pulling in the necessary declarations from , each driver copies this code into their own header. The goal of this series is to pull the ehci-dbgp related code into its own header to remove the need for this redundancy. Regards, Chris Rorvick Chris Rorvick (10): usb: Create separate header for ehci-dbgp fusbh200: Make Xen notification consistent with EHCI fusbh200: Remove superfluous macro definitions fusbh200: Remove duplicate ehci-dbgp declarations fusbh200: Use ehci_dbg_port struct fotg210: Make Xen notification consistent with EHCI fotg210: Remove superfluous macro definitions fotg210: Remove duplicate ehci-dbgp declarations fotg210: Use ehci_dbg_port struct usb: Remove __init from early_dbgp_init() prototype drivers/usb/host/fotg210.h| 62 ++-- drivers/usb/host/fusbh200.h | 62 ++-- include/linux/usb/ehci-dbgp.h | 83 +++ include/linux/usb/ehci_def.h | 65 ++--- 4 files changed, 91 insertions(+), 181 deletions(-) create mode 100644 include/linux/usb/ehci-dbgp.h -- 1.9.3 -- 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 03/10] fusbh200: Remove superfluous macro definitions
The fusbh200_dbg_port struct is a copy of the ehci_dbg_port definition
in the header. Embedded in this definition are
a number of macros which came along for the ride. These macros are not
used in the fusbh200 driver and will conflict those in the new
header.
Signed-off-by: Chris Rorvick
---
drivers/usb/host/fusbh200.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/usb/host/fusbh200.h b/drivers/usb/host/fusbh200.h
index 6e7b8c1..da7152b 100644
--- a/drivers/usb/host/fusbh200.h
+++ b/drivers/usb/host/fusbh200.h
@@ -290,24 +290,10 @@ struct fusbh200_regs {
*/
struct fusbh200_dbg_port {
u32 control;
-#define DBGP_OWNER (1<<30)
-#define DBGP_ENABLED (1<<28)
-#define DBGP_DONE (1<<16)
-#define DBGP_INUSE (1<<10)
-#define DBGP_ERRCODE(x)(((x)>>7)&0x07)
-# define DBGP_ERR_BAD 1
-# define DBGP_ERR_SIGNAL 2
-#define DBGP_ERROR (1<<6)
-#define DBGP_GO(1<<5)
-#define DBGP_OUT (1<<4)
-#define DBGP_LEN(x)(((x)>>0)&0x0f)
u32 pids;
-#define DBGP_PID_GET(x)(((x)>>16)&0xff)
-#define DBGP_PID_SET(data, tok)(((data)<<8)|(tok))
u32 data03;
u32 data47;
u32 address;
-#define DBGP_EPADDR(dev, ep) (((dev)<<8)|(ep))
};
#ifdef CONFIG_EARLY_PRINTK_DBGP
--
1.9.3
--
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 02/10] fusbh200: Make Xen notificaiton consistent with EHCI
If CONFIG_XEN_DOM0 is enabled, the ehci-dbgp driver notifies Xen of
controller reset events via xen_dbgp_reset_prep() and
xen_dbgp_external_startup() (via calls to xen_dbgp_op().) Otherwise
defines them as no-ops to disable this logic.
The fusbh200 driver copies much of the dbgp code from ehci_def.h, but it
unconditionally defines the Xen hooks as no-ops, effectively disabling
these notifications when CONFIG_EARLY_PRINTK_DBGP is disabled. When
enabled, though, notifying Xen is dependent on CONFIG_XEN_DOM0 due to
fusbh200 leveraging the ehci-dbgp driver.
The following table compares the implementations of xen_dbgp_reset_prep()
and xen_dbgp_external_startup() in the ehci-dbgp and fusbh200 drivers
under the relevant configurations:
EARLY_PRINTK_DBGP? XEN_DOM0? ehci-dbgp fusbh200
-- - - -
n n no-op no-op
n y xen_dbgp_op() no-op
y n no-op no-op
y y xen_dbgp_op() xen_dbgp_op()
This suggests that fusbh200 is, at best, indifferent to whether Xen is
notified of these events. Make fusbh200 consistent with ehci-dbgp as a
step towards consolidating this code duplication.
Signed-off-by: Chris Rorvick
---
drivers/usb/host/fusbh200.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/host/fusbh200.h b/drivers/usb/host/fusbh200.h
index 6b719e0..6e7b8c1 100644
--- a/drivers/usb/host/fusbh200.h
+++ b/drivers/usb/host/fusbh200.h
@@ -318,6 +318,10 @@ extern struct console early_dbgp_console;
struct usb_hcd;
+#ifdef CONFIG_XEN_DOM0
+extern int xen_dbgp_reset_prep(struct usb_hcd *);
+extern int xen_dbgp_external_startup(struct usb_hcd *);
+#else
static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
{
return 1; /* Shouldn't this be 0? */
@@ -327,6 +331,7 @@ static inline int xen_dbgp_external_startup(struct usb_hcd
*hcd)
{
return -1;
}
+#endif
#ifdef CONFIG_EARLY_PRINTK_DBGP
/* Call backs from fusbh200 host driver to fusbh200 debug driver */
--
1.9.3
--
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 01/10] usb: Create separate header for ehci-dbgp
The FUSBH200 and FOTG210 controllers implement sufficiently EHCI-
compatible debug ports to leverage ehci-dbgp from their respective
drivers. Rather than including header, though,
they replicate the necessary declarations in their own headers. Move
the ehci-dbgp stuff into its own header as a first step towards removing
this redundancy.
Signed-off-by: Chris Rorvick
---
include/linux/usb/ehci-dbgp.h | 84 +++
include/linux/usb/ehci_def.h | 65 ++---
2 files changed, 86 insertions(+), 63 deletions(-)
create mode 100644 include/linux/usb/ehci-dbgp.h
diff --git a/include/linux/usb/ehci-dbgp.h b/include/linux/usb/ehci-dbgp.h
new file mode 100644
index 000..796c1cd
--- /dev/null
+++ b/include/linux/usb/ehci-dbgp.h
@@ -0,0 +1,84 @@
+/*
+ * Standalone EHCI usb debug driver
+ *
+ * Originally written by:
+ * Eric W. Biederman" and
+ * Yinghai Lu
+ *
+ * Changes for early/late printk and HW errata:
+ * Jason Wessel
+ * Copyright (C) 2009 Wind River Systems, Inc.
+ *
+ */
+
+#ifndef __LINUX_USB_EHCI_DBGP_H
+#define __LINUX_USB_EHCI_DBGP_H
+
+#include
+#include
+
+/* Appendix C, Debug port ... intended for use with special "debug devices"
+ * that can help if there's no serial console. (nonstandard enumeration.)
+ */
+struct ehci_dbg_port {
+ u32 control;
+#define DBGP_OWNER (1<<30)
+#define DBGP_ENABLED (1<<28)
+#define DBGP_DONE (1<<16)
+#define DBGP_INUSE (1<<10)
+#define DBGP_ERRCODE(x)(((x)>>7)&0x07)
+# define DBGP_ERR_BAD 1
+# define DBGP_ERR_SIGNAL 2
+#define DBGP_ERROR (1<<6)
+#define DBGP_GO(1<<5)
+#define DBGP_OUT (1<<4)
+#define DBGP_LEN(x)(((x)>>0)&0x0f)
+ u32 pids;
+#define DBGP_PID_GET(x)(((x)>>16)&0xff)
+#define DBGP_PID_SET(data, tok)(((data)<<8)|(tok))
+ u32 data03;
+ u32 data47;
+ u32 address;
+#define DBGP_EPADDR(dev, ep) (((dev)<<8)|(ep))
+};
+
+#ifdef CONFIG_EARLY_PRINTK_DBGP
+#include
+extern int __init early_dbgp_init(char *s);
+extern struct console early_dbgp_console;
+#endif /* CONFIG_EARLY_PRINTK_DBGP */
+
+struct usb_hcd;
+
+#ifdef CONFIG_XEN_DOM0
+extern int xen_dbgp_reset_prep(struct usb_hcd *);
+extern int xen_dbgp_external_startup(struct usb_hcd *);
+#else
+static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
+{
+ return 1; /* Shouldn't this be 0? */
+}
+
+static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
+{
+ return -1;
+}
+#endif
+
+#ifdef CONFIG_EARLY_PRINTK_DBGP
+/* Call backs from ehci host driver to ehci debug driver */
+extern int dbgp_external_startup(struct usb_hcd *);
+extern int dbgp_reset_prep(struct usb_hcd *);
+#else
+static inline int dbgp_reset_prep(struct usb_hcd *hcd)
+{
+ return xen_dbgp_reset_prep(hcd);
+}
+
+static inline int dbgp_external_startup(struct usb_hcd *hcd)
+{
+ return xen_dbgp_external_startup(hcd);
+}
+#endif
+
+#endif /* __LINUX_USB_EHCI_DBGP_H */
diff --git a/include/linux/usb/ehci_def.h b/include/linux/usb/ehci_def.h
index daec99a..966889a 100644
--- a/include/linux/usb/ehci_def.h
+++ b/include/linux/usb/ehci_def.h
@@ -19,6 +19,8 @@
#ifndef __LINUX_USB_EHCI_DEF_H
#define __LINUX_USB_EHCI_DEF_H
+#include
+
/* EHCI register interface, corresponds to EHCI Revision 0.95 specification */
/* Section 2.2 Host Controller Capability Registers */
@@ -190,67 +192,4 @@ struct ehci_regs {
#define USBMODE_EX_HC (3<<0) /* host controller mode */
};
-/* Appendix C, Debug port ... intended for use with special "debug devices"
- * that can help if there's no serial console. (nonstandard enumeration.)
- */
-struct ehci_dbg_port {
- u32 control;
-#define DBGP_OWNER (1<<30)
-#define DBGP_ENABLED (1<<28)
-#define DBGP_DONE (1<<16)
-#define DBGP_INUSE (1<<10)
-#define DBGP_ERRCODE(x)(((x)>>7)&0x07)
-# define DBGP_ERR_BAD 1
-# define DBGP_ERR_SIGNAL 2
-#define DBGP_ERROR (1<<6)
-#define DBGP_GO(1<<5)
-#define DBGP_OUT (1<<4)
-#define DBGP_LEN(x)(((x)>>0)&0x0f)
- u32 pids;
-#define DBGP_PID_GET(x)(((x)>>16)&0xff)
-#define DBGP_PID_SET(data, tok)(((data)<<8)|(tok))
- u32 data03;
- u32 data47;
- u32 address;
-#define DBGP_EPADDR(dev, ep) (((dev)<<8)|(ep))
-};
-
-#ifdef CONFIG_EARLY_PRINTK_DBGP
-#include
-extern int __init early_dbgp_init(char *s);
-extern struct console early_dbgp_console;
-#endif /* CONFIG_EARLY_PRINTK_DBGP */
-
-struct usb_hcd;
-
-#ifdef CONFIG_XEN_DOM0
-extern int xen_dbgp_reset_prep(struct usb_hcd *);
-extern int xen_dbgp_external_startup(struct usb_hcd *);
-#else
-static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
-{
- return 1; /* Shouldn't this be 0? */
-}
-
-static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
-{
- return -1;
-}
-#endif
-
-#ifdef CONFIG_EARLY_PRINTK_DBGP
-/* Call
[PATCH 04/10] fusbh200: Remove duplicate ehci-dbgp declarations
Now that ehci-dbgp has its own header, use it rather than duplicating
the declarations, etc.
Signed-off-by: Chris Rorvick
---
drivers/usb/host/fusbh200.h | 40 ++--
1 file changed, 2 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/host/fusbh200.h b/drivers/usb/host/fusbh200.h
index da7152b..47aecfc 100644
--- a/drivers/usb/host/fusbh200.h
+++ b/drivers/usb/host/fusbh200.h
@@ -1,6 +1,8 @@
#ifndef __LINUX_FUSBH200_H
#define __LINUX_FUSBH200_H
+#include
+
/* definitions used for the EHCI driver */
/*
@@ -296,44 +298,6 @@ struct fusbh200_dbg_port {
u32 address;
};
-#ifdef CONFIG_EARLY_PRINTK_DBGP
-#include
-extern int __init early_dbgp_init(char *s);
-extern struct console early_dbgp_console;
-#endif /* CONFIG_EARLY_PRINTK_DBGP */
-
-struct usb_hcd;
-
-#ifdef CONFIG_XEN_DOM0
-extern int xen_dbgp_reset_prep(struct usb_hcd *);
-extern int xen_dbgp_external_startup(struct usb_hcd *);
-#else
-static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
-{
- return 1; /* Shouldn't this be 0? */
-}
-
-static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
-{
- return -1;
-}
-#endif
-
-#ifdef CONFIG_EARLY_PRINTK_DBGP
-/* Call backs from fusbh200 host driver to fusbh200 debug driver */
-extern int dbgp_external_startup(struct usb_hcd *);
-extern int dbgp_reset_prep(struct usb_hcd *hcd);
-#else
-static inline int dbgp_reset_prep(struct usb_hcd *hcd)
-{
- return xen_dbgp_reset_prep(hcd);
-}
-static inline int dbgp_external_startup(struct usb_hcd *hcd)
-{
- return xen_dbgp_external_startup(hcd);
-}
-#endif
-
/*-*/
#defineQTD_NEXT(fusbh200, dma) cpu_to_hc32(fusbh200, (u32)dma)
--
1.9.3
--
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 00/10] MA USB drivers cover letter
[with a valid Message-ID] On Tue, Nov 04, 2014 at 10:00:32AM +0100, Bjørn Mork wrote: > [added linux-usb@vger.kernel.org Cc] > > Stephanie Wallick writes: > > > Media Agnostic (MA) USB enables the USB protocol to be used over a wide > > range of physical media. MA USB is a relatively new protocol and is > > currently unsupported in the Linux kernel. This patch set adds the > > following drivers with the following capabilities: > > > > 1) MA USB Host: > > - provides functionality of a USB Host Controller. > > - implements MA USB protocol for a MA USB host. > > - provides MA USB packet transport over TCP > > > > 2) MA USB Device: > > - provides functionality of a USB Device Controller. > > - implements MA USB protocol for a MA USB device. > > - provides MA USB packet transport over TCP > > Nice. But don't you think this deserves the attention of the linux-usb > mailing list? Yes, Greg's attention is of course good to have too :-) > But I believe this is of interest to more people, who might not read > everything on linux-kernel. This is probably more relevant/interesting to the people on linux-usb. Since we were trying to get this driver into staging, we thought linux-kernel was the right place to send the patches. We can send the next set out to linux-usb as well. > Has there been any thought/discussion about the relationship to the > existing usbip drivers, which just moved out of staging? Is a usbip > userspace compatibility layer feasible sometime in the future? That discussion hasn't happened. usbip has a different protocol than MA USB, so much of the code cannot be reused. I just briefly looked into the userspace code for usbip. It looks like the userspace compatibility layer is just a utility for establishing the TCP connection between the host and device & choosing what devices to connect, correct? We have a similar utility (see patch 9/10) which could probably be replaced by the usbip userspace utilities. Thanks, Sean -- 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 RESEND 00/10] Create separate header for ehci-dbgp driver
On Mon, Nov 3, 2014 at 5:09 PM, Greg Kroah-Hartman wrote: > It deletes lines of code overall, which looks good to me. Feel free to > resend without the "RFC" and I will queue it up. > > thanks, > > greg k-h Done. I went through the patches by hand to double check spelling based on Daniele catching the s/notificaiton/notification/ typo but somehow failed to make that fix to patch 02. I can resend if you'd like, sorry for the silly error. Chris -- 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 net-next] r8152: disable the tasklet by default
Let the tasklet only be enabled after open(), and be disabled for
the other situation. The tasklet is only necessary after open() for
tx/rx, so it could be disabled by default.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 8ded08e..fd41675 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2943,6 +2943,8 @@ static int rtl8152_open(struct net_device *netdev)
netif_warn(tp, ifup, netdev, "intr_urb submit failed: %d\n",
res);
free_all_mem(tp);
+ } else {
+ tasklet_enable(&tp->tl);
}
mutex_unlock(&tp->control);
@@ -2958,6 +2960,7 @@ static int rtl8152_close(struct net_device *netdev)
struct r8152 *tp = netdev_priv(netdev);
int res = 0;
+ tasklet_disable(&tp->tl);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
@@ -2975,9 +2978,7 @@ static int rtl8152_close(struct net_device *netdev)
*/
rtl_runtime_suspend_enable(tp, false);
- tasklet_disable(&tp->tl);
tp->rtl_ops.down(tp);
- tasklet_enable(&tp->tl);
mutex_unlock(&tp->control);
@@ -3887,12 +3888,15 @@ static int rtl8152_probe(struct usb_interface *intf,
else
device_set_wakeup_enable(&udev->dev, false);
+ tasklet_disable(&tp->tl);
+
netif_info(tp, probe, netdev, "%s\n", DRIVER_VERSION);
return 0;
out1:
usb_set_intfdata(intf, NULL);
+ tasklet_kill(&tp->tl);
out:
free_netdev(netdev);
return ret;
--
1.9.3
--
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 2/3] usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe
On 11/5/2014 12:58 AM, Alan Stern wrote:
On Tue, 4 Nov 2014, Lu Baolu wrote:
xhci: clear root port wake on bits if controller isn't wake-up capable
When system is being suspended, if host device is not wakeup capable,
xhci_suspend() needs to clear all root port wake on bits. Otherwise,
some platforms may generate spurious wakeup, even if PCI PME# is dis-
abled.
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..cd57aae 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -35,6 +35,8 @@
#define DRIVER_AUTHOR "Sarah Sharp"
#define DRIVER_DESC "'eXtensible' Host Controller (xHC) Driver"
+#define PORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
+
/* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared
*/
static int link_quirk;
module_param(link_quirk, int, S_IRUGO | S_IWUSR);
@@ -851,6 +853,42 @@ static void xhci_clear_command_ring(struct xhci_hcd *xhci)
xhci_set_cmd_ring_deq(xhci);
}
+static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
+{
+ int port_index;
+ __le32 __iomem **port_array;
+ unsigned long flags;
+ u32 t1, t2;
+
+ spin_lock_irqsave(&xhci->lock, flags);
+
+ /* disble usb3 ports Wake bits*/
+ port_index = xhci->num_usb3_ports;
+ port_array = xhci->usb3_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t2 = xhci_port_state_to_neutral(t1);
+ t2 &= ~PORT_WAKE_BITS;
+ t1 = xhci_port_state_to_neutral(t1);
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ /* disble usb2 ports Wake bits*/
+ port_index = xhci->num_usb2_ports;
+ port_array = xhci->usb2_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t2 = xhci_port_state_to_neutral(t1);
+ t2 &= ~PORT_WAKE_BITS;
+ t1 = xhci_port_state_to_neutral(t1);
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ spin_unlock_irqrestore(&xhci->lock, flags);
+}
+
/*
* Stop HC (not bus-specific)
*
@@ -868,6 +906,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
xhci->shared_hcd->state != HC_STATE_SUSPENDED)
return -EINVAL;
+ /* Clear root port wake on bits if not wakeup capable. */
+ if (!device_may_wakeup(hcd->self.controller))
+ xhci_disable_port_wake_on_bits(xhci);
+
/* Don't poll the roothubs on bus suspend. */
xhci_dbg(xhci, "%s: stopping port polling.\n", __func__);
clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
This is better but still wrong. Remember, this same code gets called
for system suspend _and_ for runtime suspend. During runtime suspend,
wakeup is always supposed to be turned on, even if device_may_wakeup()
is false. That's because device_may_wakeup() refers only to system
suspend. What you need to test is the do_wakeup flag, which should be
passed into xhci_suspend() by xhci_pci_suspend() and
xhci_plat_suspend().
Yes, it should cover runtime suspend as well. Thanks for the comments. I
will resend the patch.
Another problem is in the patch description and the comments. If
device_may_wakeup() returns false, it doesn't mean the controller isn't
wakeup-capable -- it means the controller isn't _allowed_ to wake up
the system. Those are two different things.
Accept, I will change this in new patch version.
Finally, the code in xhci_disable_port_wake_on_bits() looks a little
peculiar -- I'm not sure about all those calls to
xhci_port_state_to_neutral(). But I'm not an expert on that; Mathias
will have to advise on it.
This part of code was written with reference to code in xhci-hub.c.
Comments of xhci_port_state_to_neutral():
/*
* Given a port state, this function returns a value that would result
in the
* port being in the same state, if the value was written to the port
status
* control register.
* Save Read Only (RO) bits and save read/write bits where
* writing a 0 clears the bit and writing a 1 sets the bit (RWS).
* For all other types (RW1S, RW1CS, RW, and RZ), writing a '0' has no
effect.
*/
This calculation is used to avoid side effect of changing other bit fields.
Thanks,
-baolu
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: dwc3: remove warning of disable scramble check
On Tue, Nov 04, 2014 at 08:47:26AM -0600, Felipe Balbi wrote: > On Tue, Nov 04, 2014 at 05:29:51PM +0800, Huang Rui wrote: > > Some SoC's FPGA platform will need this quirk, but it will complain if > > running at true SoC platform. This is a normal case, so remove this > > warning. > > nope, why do you need disable_scramble on actual SoC ? Without an > erratum number I will not accept this, sorry. > Oh, that's my faulty. I can set disable_scramble_quirk=false after actual SoC, at that time, we can drop FPGA support. :) Thanks, 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
[PATCH v3 0/3] Rework "xhci: clear root port wake on bits if controller isn't wake-up capable"
This serie of patch reworks commit ff8cbf250b448aac35589f6075082c3fcad8a8fe. This has been discussed at http://www.spinics.net/lists/linux-usb/msg114986.html It also includes a patch to fix a comment in drivers/usb/host/xhci.h. Changes in v3: * Need to consider run-time suspend as well. * Change "wake-up capable" to "allowed to do wakeup" in both comments and patch description. * Add "Suggested-by: Alan Stern" Changes in v2: * Should not be a quirk. * Should be applied to all xhci controllers. Lu Baolu (3): usb: xhci: Revert "xhci: clear root port wake on bits if controller isn't wake-up capable" usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe usb: xhci: fix comment for PORT_DEV_REMOVE drivers/usb/host/xhci-hub.c | 5 + drivers/usb/host/xhci-pci.c | 2 +- drivers/usb/host/xhci-plat.c | 10 +- drivers/usb/host/xhci.c | 44 +++- drivers/usb/host/xhci.h | 4 ++-- 5 files changed, 56 insertions(+), 9 deletions(-) -- 1.9.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 v3 1/3] usb: xhci: Revert "xhci: clear root port wake on bits if controller isn't wake-up capable"
This reverts commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
Commit ff8cbf250b448aac35589f6075082c3fcad8a8fe triggers the bug logged at
https://bugzilla.kernel.org/show_bug.cgi?id=85701
Signed-off-by: Lu Baolu
Reported-by: Dmitry Nezhevenko
---
drivers/usb/host/xhci-hub.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 696160d..388cfd8 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,7 +22,6 @@
#include
-#include
#include
#include "xhci.h"
@@ -1149,9 +1148,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd->self.root_hub->do_remote_wakeup
- && device_may_wakeup(hcd->self.controller)) {
-
+ if (hcd->self.root_hub->do_remote_wakeup) {
if (t1 & PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 &= ~PORT_WKCONN_E;
--
1.9.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 v3 3/3] usb: xhci: fix comment for PORT_DEV_REMOVE
According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means "Device is non-removable".
Signed-off-by: Lu Baolu
Reported-by: Juro Bystricky
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index d745715..ab36bbb 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -358,7 +358,7 @@ struct xhci_op_regs {
/* wake on over-current (enable) */
#define PORT_WKOC_E(1 << 27)
/* bits 28:29 reserved */
-/* true: device is removable - for USB 3.0 roothub emulation */
+/* true: device is non-removable - for USB 3.0 roothub emulation */
#define PORT_DEV_REMOVE(1 << 30)
/* Initiate a warm port reset - complete when PORT_WRC is '1' */
#define PORT_WR(1 << 31)
--
1.9.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 v3 2/3] usb: xhci: This reworks ff8cbf250b448aac35589f6075082c3fcad8a8fe
xhci: clear root port wake on bits if controller isn't allowed to do wakeup
When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.
Signed-off-by: Lu Baolu
Suggested-by: Alan Stern
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-plat.c | 10 +-
drivers/usb/host/xhci.c | 44 +++-
drivers/usb/host/xhci.h | 2 +-
4 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 280dde9..d3fa3c2 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -291,7 +291,7 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool
do_wakeup)
if (xhci->quirks & XHCI_COMP_MODE_QUIRK)
pdev->no_d3cold = true;
- return xhci_suspend(xhci);
+ return xhci_suspend(xhci, do_wakeup);
}
static int xhci_pci_resume(struct usb_hcd *hcd, bool hibernated)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..646300c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -204,7 +204,15 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- return xhci_suspend(xhci);
+ /*
+* xhci_suspend() needs `do_wakeup` to know whether host is allowed
+* to do wakeup during suspend. Since xhci_plat_suspend is currently
+* only designed for system suspend, device_may_wakeup() is enough
+* to dertermine whether host is allowed to do wakeup. Need to
+* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
+* also applies to runtime suspend.
+*/
+ return xhci_suspend(xhci, device_may_wakeup(dev));
}
static int xhci_plat_resume(struct device *dev)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..70d607b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -35,6 +35,8 @@
#define DRIVER_AUTHOR "Sarah Sharp"
#define DRIVER_DESC "'eXtensible' Host Controller (xHC) Driver"
+#definePORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
+
/* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared */
static int link_quirk;
module_param(link_quirk, int, S_IRUGO | S_IWUSR);
@@ -851,13 +853,49 @@ static void xhci_clear_command_ring(struct xhci_hcd *xhci)
xhci_set_cmd_ring_deq(xhci);
}
+static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
+{
+ int port_index;
+ __le32 __iomem **port_array;
+ unsigned long flags;
+ u32 t1, t2;
+
+ spin_lock_irqsave(&xhci->lock, flags);
+
+ /* disble usb3 ports Wake bits*/
+ port_index = xhci->num_usb3_ports;
+ port_array = xhci->usb3_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t2 = xhci_port_state_to_neutral(t1);
+ t2 &= ~PORT_WAKE_BITS;
+ t1 = xhci_port_state_to_neutral(t1);
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ /* disble usb2 ports Wake bits*/
+ port_index = xhci->num_usb2_ports;
+ port_array = xhci->usb2_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t2 = xhci_port_state_to_neutral(t1);
+ t2 &= ~PORT_WAKE_BITS;
+ t1 = xhci_port_state_to_neutral(t1);
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ spin_unlock_irqrestore(&xhci->lock, flags);
+}
+
/*
* Stop HC (not bus-specific)
*
* This is called when the machine transition into S3/S4 mode.
*
*/
-int xhci_suspend(struct xhci_hcd *xhci)
+int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
{
int rc = 0;
unsigned intdelay = XHCI_MAX_HALT_USEC;
@@ -868,6 +906,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
xhci->shared_hcd->state != HC_STATE_SUSPENDED)
return -EINVAL;
+ /* Clear root port wake on bits if wakeup not allowed. */
+ if (!do_wakeup)
+ xhci_disable_port_wake_on_bits(xhci);
+
/* Don't poll the roothubs on bus suspend. */
xhci_dbg(xhci, "%s: stopping port polling.\n", __func__);
clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index df76d64..d745715 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1746,7 +1746,7 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t
get_quirks);
void xhci_init_driver(struct hc_driver *drv, int (*setup_fn)(struct usb_hcd
*));
Re: [Regression][v3.17][v3.18] USB: Fix persist resume of some SS USB devices
Hello Joe,
On Wed, Nov 05, 2014 at 06:20:06AM +0800, Joseph Salisbury wrote:
> Hello Pratyush,
>
> A kernel bug report was opened against Ubuntu [0]. After a kernel
> bisect, it was found that reverting the following commit resolved this bug:
>
> commit a40178b2fa6ad87670fb1e5fa4024db00c149629
> Author: Pratyush Anand
> Date: Fri Jul 18 12:37:10 2014 +0530
>
> USB: Fix persist resume of some SS USB devices
>
> The regression was introduced as of v3.17-rc1. The regression still
> exists in the 3.18-rc3 mainline kernel, and has made it's way into the
> stable kernels.
Its strange, as per my understanding patch does not introduce any side
effect for devices whose resume time is normal. So, if a device is
connected to the SS port and it was working after resume from
suspend to ram without this patch, then that device should still work
with this patch.
Infact this has resolved another bug reported to bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=53211
>
> I was hoping to get your feedback, since you are the patch author. Do
> you think gathering any additional data will help diagnose this issue,
Yaa, sure additional info will help to understand the issue.
-- dmesg log of suspend resume when this patch is not applied and also
when applied.
-- dmesg log with following additional debug print.
@@ -3318,6 +3318,7 @@ static int wait_for_ss_port_enable(struct usb_device
*udev,
int status = 0, delay_ms = 0;
while (delay_ms < 2000) {
+ printk("%s:portstatus is %x and portchange is %x\n", __func__,
*portstatus, *portchange);
if (status || *portstatus & USB_PORT_STAT_CONNECTION)
break;
> or would it be best to submit a revert request?
Let me see what is the portstatus value and why didn't it break loop in first
iteration if device was OK.
Regards
Pratyush
>
>
> Thanks,
>
> Joe
>
> [0] http://pad.lv/1384041
--
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: btusb_intr_complete returns -EPIPE
>> >> Split packet transactions are hidden. I could see them by clicking on >> >> the (Show/Hide Split transactions) button. For INT IN, I could see >> >> only Start Split packet. >> >> >> >> I attached([2014-10-28 session 144012] Trace0003.rar) complete log for >> >> this scenario. >> > >> > How come the log doesn't contain any SOF packets? >> >> >> To avoid recording a huge quantity of data , I enabled the "Drop Start >> of Frames" filter in the recording options. > > Can you do it again, but this time keep the SOF packets? > > You don't have to post the entire analyzer log. Just extract 3 or 4 ms > from the middle, where it shows the SSPLITS but no CSPLITS for the > interrupt endpoints, and post only that portion. > I tried again, I keep getting STALL's but this time I see CSPLITS for the interrupt end points. [root@banunxcas29 ns06]# lsusb -t 1-1.5.1:1.2: No such file or directory 1-1.5.2:1.2: No such file or directory 1-1.5.3:1.2: No such file or directory 1-1.5.4:1.2: No such file or directory /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M |__ Port 5: Dev 51, If 0, Class=hub, Driver=hub/4p, 480M |__ Port 1: Dev 52, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 1: Dev 52, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 1: Dev 52, If 2, Class=app., Driver=, 12M |__ Port 2: Dev 53, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 2: Dev 53, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 2: Dev 53, If 2, Class=app., Driver=, 12M |__ Port 3: Dev 56, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 3: Dev 56, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 3: Dev 56, If 2, Class=app., Driver=, 12M |__ Port 4: Dev 55, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 4: Dev 55, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 4: Dev 55, If 2, Class=app., Driver=, 12M Here Dev 51 is external USB-2 hub. usbmon log: 8800b2cce6c0 1558099725 C Ii:1:055:1 -32:1 0 8800b2cce6c0 1558099740 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 1558435684 C Ii:1:055:1 -32:1 0 8800b2cce6c0 1558435700 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 1558447773 C Ii:1:055:1 -32:1 0 8800b2cce6c0 1558447790 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 1562003759 C Ii:1:055:1 -32:1 0 8800b2cce6c0 1562003777 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 1835091798 C Ii:1:055:1 -32:1 0 8800b2cce6c0 1835091818 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 2360295770 C Ii:1:055:1 -32:1 0 8800b2cce6c0 2360295785 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 2360307814 C Ii:1:055:1 -32:1 0 8800b2cce6c0 2360307827 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 2746327776 C Ii:1:055:1 -32:1 0 8800b2cce6c0 2746327796 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 2750455832 C Ii:1:055:1 -32:1 0 8800b2cce6c0 2750455844 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 2751751777 C Ii:1:055:1 -32:1 0 8800b2cce6c0 2751751788 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 2752707689 C Ii:1:055:1 -32:1 0 8800b2cce6c0 2752707707 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 2762271761 C Ii:1:055:1 -32:1 0 8800b2cce6c0 2762271776 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 2977131824 C Ii:1:055:1 -32:1 0 8800b2cce6c0 2977131835 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 3602679779 C Ii:1:055:1 -32:1 0 8800b2cce6c0 3602679798 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 456023739 C Ii:1:055:1 -32:1 0 8800b2cce6c0 456023758 S Ii:1:055:1 -115:1 16 < 8800b2cce6c0 456231695 C Ii:1:055:1 -32:1 0 8800b2cce6c0 456231712 S Ii:1:055:1 -115:1 16 < Dev 55 usb log: SSPLIT IN transaction 55 1 HS No data 0.000 238 117 Start of Frame (2) HS 228.0 -> 228.1 0.000 340 583 CSPLIT IN transaction 55 1 NAK HS No data 0.000 489 817 Start of Frame (6) HS 228.2 -> 228.7 0.000 590 617 SSPLIT IN transaction 55 1 HS No data 0.001 238 117 Start of Frame (2) HS 229.0 -> 229.1 0.001 340 733 CSPLIT IN transaction 55 1 NAK HS No data 0.001 489 850 Start of Frame (6) HS 229.2 -> 229.7 0.001 590 767 SSPLIT IN transaction 55 1 HS No data 0.002 238 933 Start of Frame (2) HS 230.0 -> 230.1 0.002 340 867 CSPLIT IN transaction 55 1 NAK HS No data 0.002 489 933 Start of Frame (6) HS 230.2 -> 230.7 0.002 590 900 SSPLIT IN transaction 55 1 HS No data 0.003 238 967 Start of Frame (2) HS 231.0 -> 231.1 0.003 341 017 CSPLIT IN transaction 55 1 NAK HS No data 0.003 489 900 Start of Frame (6) HS 231.2 -> 231.7 0.003 591 050 SSPLIT IN transaction 55 1 HS No data 0.004 238 950 Start of Frame (2) HS 232.0 -> 232.1 0.004 341 150 CSPLIT IN tr
