Re: [PATCHv2 1/2] extcon: add driver for Intel USB mux

[Heikki Krogerus]

Hi,

> I do never want to add some specific funtcion for only this driver.
> I think is not appropriate way.
> - intel_usb_mux_unregister
> - intel_usb_mux_register
> 
> The client driver using extcon driver should use the standard extcon API
> for code consistency. Also, I'll do the more detailed review for this patch.

The internal mux we are controlling here is physically separate
device. Ideally we could populate child device for it, but since that
is not possible because of the resource conflict, we use the library
approach, which is really not that uncommon.

I don't think I agree with your point even at general level. The
control required to handle this mux, even though simple, is enough to
deserve to be separated from xHCI code. xHCI should not need to care
about anything else expect does it have the mux, i.e. does it need to
register it or not. It should not need to care about how it needs to
be controlled or even what it is. We may decide to create something
else out of it instead of an extcon device later.

But in any case, the mux is available on all new Intel platforms, but
it needs to be controlled by OS only in few "special" cases. We can
not force xHCI (or pci-quirks.c to be more precise) to be aware of
these "special" cases. The only way to make it work like that would
bet by using ifdefs, and we really really don't want that.

And please also note that, though for now we only expect the mux
control registers to be part of xHCI MMIO, that is not always the
case. The control registers are part of the device controller MMIO on
some platforms. We do not want to duplicate the whole control of the
mux if/when we need the OS to be in control of it on a platform that
has those control registers mapped somewhere else then xHCI MMIO,

So I would say that we have pretty good justification for separating
the mux control, which means unfortunately custom API in this case.

But if you would prefer that we put the files somewhere else then
drivers/extcon/ and include/linux/extcon/ I'm fine with that. If you
like, we can put it to drivers/usb/host/ as that is where
pci-quirks.c is. That way I think we can also put the header to
include/usb/.


Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: xhci: fix config fail of FS hub behind a HS hub with MTT

[Mathias Nyman]

On 03.12.2015 08:14, Chunfeng Yun wrote:

if a full speed hub connects to a high speed hub which
supports MTT, the MTT field of its slot context will be set
to 1 when xHCI driver setups an xHCI virtual device in
xhci_setup_addressable_virt_dev(); once usb core fetch its
hub descriptor, and need to update the xHC's internal data
structures for the device, the HUB field of its slot context
will be set to 1 too, meanwhile MTT is also set before,
this will cause configure endpoint command fail, so in the
case, we should clear MTT to 0 for full speed hub according
to section 6.2.2

Signed-off-by: Chunfeng Yun 
---


Thanks, patch added to queue

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] net: qmi_wwan: MDM9x30 support

[Aleksander Morgado]

On Thu, Dec 3, 2015 at 7:24 PM, Bjørn Mork  wrote:
> We add new device IDs all the time, often without any testing on
> actual hardware. This is usually OK as long as the device is similar
> to already supported devices, using the same chipset and firmware
> basis.  But the Sierra Wireless MC7455 is an example of a new chipset
> generation. Adding it based on assumed similarity with its ancestors
> proved too optimistic.
>
> This series adds the missing bits and pieces necessary to support LTE
> Advanced modems based on the Qualcomm MDM9x30 chipset. A big thanks to
> Sierra Wireless for providing MC7455 samples for testing
>
> The most important change is the "raw-ip" support. The series also
> adds a necessary control request, removes an unsupported device ID,
> and adds a driver specific entry in MAINTAINERS.
>
> A few random notes about "raw-ip":
>
> "I rather have these all running in raw IP mode. The 802.3 framing is
> utterly stupid." - Marcel Holtmann in Jan 2012 [1]
>
> Marcel was right.  I should have listened to him. What more can I say?
>
> The 802.3 framing has provided a steady supply of firmware bugs for
> many years. We've added driver workarounds for many of these, but
> there are still known bugs where the workaround is so yucky that we
> have refused to apply it. But all that is over now.  The latest
> generation Qualcomm chips no longer supports 802.3 framing at all.
>
> I had two open questions regarding the "raw-ip" userspace API:
>
> 1) Should we continue faking an ethernet device, even if we don't use
>the L2 headers on the USB link anymore?
>
>There was a vote in favour of the "headerless" device. This is the
>honest representation of the hardware/firmware interface.
>
> 2) What input should the driver base its framing on?
>
>Snooping or directly manipulating QMI is considered out of the
>question. We delegated all QMI handling to userspace from the
>beginning.
>
>We have so far required userspace to configure the firmware for
>"802.3" framing, or fail if that proved impossible.  This
>requirement is now changed.  Userspace must now inform the driver
>if it negotiates "raw-ip" framing.  Two alternative interfaces were
>proposed:
> - ethtool private driver flag, or
> - sysfs file
>
>The NetworkManager/ModemManager developers were in favour of the
>sysfs alternative.
>
> These questions (or any other you migh have :) are of course still
> open.  This patch set presents the solutions I currently prefer,
> considering the above.
>
> All comments are appreciated, even simple '+1' ones.
>

+1 from me as well.

We still need to decide how to manage this in userspace once the
kernel part is ready. For all pre-WDA devices, I'd use 802-3 as that
is what we've all been using. For WDA capable devices, we should
likely query what the current data link layer mode is, and ask the
kernel to use that one via sysfs; or, default to raw-ip in those,
don't know.

-- 
Aleksander
https://aleksander.es
--
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: phy: Remove unused Renesas R-Car (Gen1) USB PHY driveer

[Geert Uytterhoeven]

As of commit 3d7608e4c169af03 ("ARM: shmobile: bockw: remove legacy
board file and config"), the Renesas R-Car (Gen1) USB PHY driver is no
longer used.
In theory it could still be used on R-Car Gen1 SoCs, but that would
require adding DT support to the driver. Instead, a new driver using the
generic PHY framework should be written, as was done for R-Car Gen2.

Remove the driver for good.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/usb/phy/Kconfig|  13 --
 drivers/usb/phy/Makefile   |   1 -
 drivers/usb/phy/phy-rcar-usb.c | 247 -
 include/linux/platform_data/usb-rcar-phy.h |  28 
 4 files changed, 289 deletions(-)
 delete mode 100644 drivers/usb/phy/phy-rcar-usb.c
 delete mode 100644 include/linux/platform_data/usb-rcar-phy.h

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 22e8ecb6bfbd2822..155694c1a5366215 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -186,19 +186,6 @@ config USB_MXS_PHY
 
  MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x.
 
-config USB_RCAR_PHY
-   tristate "Renesas R-Car USB PHY support"
-   depends on USB || USB_GADGET
-   depends on ARCH_R8A7778 || ARCH_R8A7779 || COMPILE_TEST
-   select USB_PHY
-   help
- Say Y here to add support for the Renesas R-Car USB common PHY driver.
- This chip is typically used as USB PHY for USB host, gadget.
- This driver supports R8A7778 and R8A7779.
-
- To compile this driver as a module, choose M here: the
- module will be called phy-rcar-usb.
-
 config USB_ULPI
bool "Generic ULPI Transceiver Driver"
depends on ARM || ARM64
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 19c0dccbb1161b11..b433e5d89be4bdda 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -23,7 +23,6 @@ obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
 obj-$(CONFIG_USB_QCOM_8X16_PHY)+= phy-qcom-8x16-usb.o
 obj-$(CONFIG_USB_MV_OTG)   += phy-mv-usb.o
 obj-$(CONFIG_USB_MXS_PHY)  += phy-mxs-usb.o
-obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
 obj-$(CONFIG_USB_ULPI) += phy-ulpi.o
 obj-$(CONFIG_USB_ULPI_VIEWPORT)+= phy-ulpi-viewport.o
 obj-$(CONFIG_KEYSTONE_USB_PHY) += phy-keystone.o
diff --git a/drivers/usb/phy/phy-rcar-usb.c b/drivers/usb/phy/phy-rcar-usb.c
deleted file mode 100644
index 1e09b83778853829..
--- a/drivers/usb/phy/phy-rcar-usb.c
+++ /dev/null
@@ -1,247 +0,0 @@
-/*
- * Renesas R-Car USB phy driver
- *
- * Copyright (C) 2012-2013 Renesas Solutions Corp.
- * Kuninori Morimoto 
- * Copyright (C) 2013 Cogent Embedded, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* REGS block */
-#define USBPCTRL0  0x00
-#define USBPCTRL1  0x04
-#define USBST  0x08
-#define USBEH0 0x0C
-#define USBOH0 0x1C
-#define USBCTL00x58
-
-/* High-speed signal quality characteristic control registers (R8A7778 only) */
-#define HSQCTL10x24
-#define HSQCTL20x28
-
-/* USBPCTRL0 */
-#define OVC2   (1 << 10) /* (R8A7779 only) */
-   /* Switches the OVC input pin for port 2: */
-   /* 1: USB_OVC2, 0: OVC2 */
-#define OVC1_VBUS1 (1 << 9) /* Switches the OVC input pin for port 1: */
-   /* 1: USB_OVC1, 0: OVC1/VBUS1   */
-   /* Function mode: set to 0  */
-#define OVC0   (1 << 8) /* Switches the OVC input pin for port 0: */
-   /* 1: USB_OVC0 pin, 0: OVC0 */
-#define OVC2_ACT   (1 << 6) /* (R8A7779 only)  */
-   /* Host mode: OVC2 polarity:*/
-   /* 1: active-high, 0: active-low*/
-#define PENC   (1 << 4) /* Function mode: output level of PENC1 pin: */
-   /* 1: high, 0: low  */
-#define OVC0_ACT   (1 << 3) /* Host mode: OVC0 polarity:   */
-   /* 1: active-high, 0: active-low*/
-#define OVC1_ACT   (1 << 1) /* Host mode: OVC1 polarity:   */
-   /* 1: active-high, 0: active-low*/
-   /* Function mode: be sure to set to 1   */
-#define PORT1  (1 << 0) /* Selects port 1 mode:*/
-   /* 1: function, 0: host 

Re: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Thu, Dec 03, 2015 at 04:31:35PM -0500, Alan Stern wrote:
>> Seemingly controller is already a pointer, so the & is redundant. No idea why
>> it didn't crash plain out. Fixing that, I can allocate, although I have some
>> other bug causing an oops somewhere else.
> Ah, an easy mistake to miss.  But you should have gotten a warning from 
> the compiler about incompatible pointer types.

I did. And I missed it, because a) things were scrolling fast, and
b) I'm used to coding with -Werror, where you simply cannot ignore this kind
of thing by accident :-) (Not to mention that I usually code C++, where this
is plain out an error, not a warning.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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 - VID/PID for Yaesu SCU-18 cable for ftdi-usb-sio

[Harald Linden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Greg,

Sorry, I tried, I just don't find the time to read the docs and bring
this patch into the form you requested. Can you just add the Yaesu
device to the definitions?

Vendor ID: 0x0584 Product ID: 0xB03A
Yaesu SCU-18 data cable made by RATOC

Cable works out of the box otherwise.

regards

Harald

On 28.11.2015 00:57, Greg KH wrote:

>> -#define RATOC_VENDOR_ID 0x0584 -#define RATOC_PRODUCT_ID_USB60F
>> 0xb020 +#define RATOC_VID0x0584
> 
> Why change this #define?

To bring all RATOC devices into the scheme that the rest of the
definitions uses.
> 
>> +#define RATOC_USB60F_PID0xB020
> 
> Why change this #define?

Same.
> 
>> +#define RATOC_YAESUSCU18_PID0xB03A /* Yaesu SCU-18 data cable
>> made by RATOC */
>> 
>> /* * Infineon Technologies
> 
> Can you combine this into the same patch, and provide a
> "Signed-off-by:" line as described in
> Documentation/SubmittingPatches?  Then we can apply the patch.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWYa99AAoJEF1OmwAaJLoDD5YP/1UfU6wj7a370tjP6aqasf2G
aS0pHZfbCUtH3EjtIyRgIoHslLGQBL/bLmDzQ+BUV5It0iOqqQXO6+m810k/1Dlj
ydUpnvWj07BPG6Vh3hlAzviiDHUu0vPBMS8WBxSBsUpoUCavLN2DtkF607uIcSse
eZbrONDuu5mudxsvQ1eD+CuczfTQmzPyUZl5qlAt0qYfgtquA9nUlWQtQCTl8Akp
fKlvUwzqlzb0u2wKTtlMEVs5a+6Jk9Bf9WeR2tBUSARqZVibKSya1n+id7H2HnSK
bx/qGZ/wUbUKqOxEHacPxe0K9IYnNDEfDIRKQRjpt27JySWog0+nVs0SW8pjdcIl
Xkpu+7HXY22KRdj51wfloP0d76Yclxz2isVqrsXOq7cvZVjI3WzSoS1wy+quzGCn
T4/YTo4SFjy5YxHUqnPGduZOBY6M941d1LnXgtH+s4a05uKfmI4keLNwYO3J4KNm
FbqLYn14aOK591HukITdk7zGzm4OFa+2EFRA7SlvPnVWRXqQAfn2xIku8JkOYQ26
GTZ2awlKRlfFzbonopOxZ2b5j0Dk11KTlfb9yZcRfWxWdvY7dlJtWFDxYUHemEHi
6/uvX79G6j7md3PNFa6mUWzAFJQz9ksGIxUfOCSpNWMppuMzY73/A9Jz6ldVHctM
u1q3db4m6DMo7Qg1qqcc
=Yj1j
-END PGP SIGNATURE-
--
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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Fri, Dec 04, 2015 at 01:29:05AM +0100, Steinar H. Gunderson wrote:
> I must be doing something wrong, because I don't seem to get any frames
> from my video capture, and when I close the application, I get a slowpath
> warning:

OK, the slowpath warning is a red herring -- it's just because I do the free
under a spinlock, and I can fix that.

There's still something that causes me to not get any frames, though.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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 5/7] usb: xhci: plat: Remove checks for optional clock in error/remove path

[Jisheng Zhang]

cc linux-usb@vger.kernel.org

On Fri, 4 Dec 2015 22:10:50 +0800
Jisheng Zhang wrote:

> Commit 63589e92c2d9 ("clk: Ignore error and NULL pointers passed to
> clk_{unprepare, disable}()") allows NULL or error pointer to be passed
> unconditionally.
> 
> This patch is to simplify probe error and remove code paths.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index d990135..62f02e5 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -197,8 +197,7 @@ put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
>  
>  disable_clk:
> - if (!IS_ERR(clk))
> - clk_disable_unprepare(clk);
> + clk_disable_unprepare(clk);
>  
>  put_hcd:
>   usb_put_hcd(hcd);
> @@ -218,8 +217,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>   usb_remove_hcd(hcd);
>   usb_put_hcd(xhci->shared_hcd);
>  
> - if (!IS_ERR(clk))
> - clk_disable_unprepare(clk);
> + clk_disable_unprepare(clk);
>   usb_put_hcd(hcd);
>  
>   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

Re: [PATCH 4/7] usb: xhci: plat: sort the headers in alphabetic order

[Jisheng Zhang]

cc linux-usb@vger.kernel.org

On Fri, 4 Dec 2015 22:10:49 +0800
Jisheng Zhang wrote:

> Sorting the headers in alphabetic order will help to reduce the conflict
> when adding new headers later.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index cd49ae5..d990135 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -11,15 +11,15 @@
>   * version 2 as published by the Free Software Foundation.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
> -#include 
>  
>  #include "xhci.h"
>  #include "xhci-mvebu.h"

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling

[Sergei Shtylyov]

Hello.

   Sorry for the grammar nitpicking but since it's in the comments, I felt 
the necessity to comment.


On 12/4/2015 5:40 AM, Chunfeng Yun wrote:


when ip fail to enter sleep mode, register access protection will


   Fails.


be disabed, at the same time if all clocks are disabled, access

 ^^^ disabled


register will hang up AHB bus.
the common case causes ip sleep fail is that after all ports enter


   Failure.


U3 but before ip enters sleep mode, a port receives a resume
signal('K'). this will happens when such as clicks mouse to try to
do remote wakeup to stop system enter suspend.


   Wake up.


so stop polling roothubs to avoid access xHCI register on bus


   Root hubs. Accessing.


suspend, and restart it when bus resume.


   Resumes. Or "is resumed", maybe?


Signed-off-by: Chunfeng Yun 
---
  drivers/usb/host/xhci-mtk.c | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index c9ab6a4..38635fb 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -696,9 +696,24 @@ static int xhci_mtk_remove(struct platform_device *dev)
  }

  #ifdef CONFIG_PM_SLEEP
+/*
+ * if ip sleep fail, and all clocks are disabled, access register will hang


   Fails.


+ * AHB bus, so stop poll roothubs to avoid regs access on bus suspend.


   Polling.


+ * and no need to check whether ip sleep fail or not; this will cause SPM to


   Failed.


+ * wakeup system immediately after system suspend complete if ip sleep


   Wake up.


+ * fail, it is what we wanted.


   Fails.


+ */

[...]

MBR, 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 6/7] usb: xhci: plat: add generic PHY support

[Jisheng Zhang]

cc linux-usb@vger.kernel.org

On Fri, 4 Dec 2015 22:10:51 +0800
Jisheng Zhang wrote:

> Marvell BG4CT SoC needs two phy: one for usb2 and another for usb3. Add
> the calls to retrieve generic PHY to xhci plat in order to support this.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 87 
> ++--
>  1 file changed, 75 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 62f02e5..bb972a6 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -73,6 +74,37 @@ static int xhci_plat_start(struct usb_hcd *hcd)
>   return xhci_run(hcd);
>  }
>  
> +static int xhci_plat_phy_init(struct usb_hcd *hcd)
> +{
> + int ret;
> +
> + if (hcd->phy) {
> + ret = phy_init(hcd->phy);
> + if (ret)
> + return ret;
> +
> + ret = phy_power_on(hcd->phy);
> + if (ret) {
> + phy_exit(hcd->phy);
> + return ret;
> + }
> + } else {
> + ret = usb_phy_init(hcd->usb_phy);
> + }
> +
> + return ret;
> +}
> +
> +static void xhci_plat_phy_exit(struct usb_hcd *hcd)
> +{
> + if (hcd->phy) {
> + phy_power_off(hcd->phy);
> + phy_exit(hcd->phy);
> + } else {
> + usb_phy_shutdown(hcd->usb_phy);
> + }
> +}
> +
>  static int xhci_plat_probe(struct platform_device *pdev)
>  {
>   struct device_node  *node = pdev->dev.of_node;
> @@ -83,6 +115,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   struct usb_hcd  *hcd;
>   struct clk  *clk;
>   struct usb_phy  *usb_phy;
> + struct phy  *phy;
>   int ret;
>   int irq;
>  
> @@ -163,22 +196,44 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
>   xhci->shared_hcd->can_do_streams = 1;
>  
> + hcd->phy = devm_phy_get(>dev, "usb2-phy");
> + if (IS_ERR(hcd->phy)) {
> + ret = PTR_ERR(hcd->phy);
> + if (ret == -EPROBE_DEFER)
> + goto put_usb3_hcd;
> + hcd->phy = NULL;
> + }
> +
> + phy = devm_phy_get(>dev, "usb-phy");
> + if (IS_ERR(phy)) {
> + ret = PTR_ERR(phy);
> + if (ret == -EPROBE_DEFER)
> + goto put_usb3_hcd;
> + phy = NULL;
> + }
> +
>   usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
>   if (IS_ERR(usb_phy)) {
>   ret = PTR_ERR(usb_phy);
>   if (ret == -EPROBE_DEFER)
>   goto put_usb3_hcd;
>   usb_phy = NULL;
> - } else {
> - ret = usb_phy_init(usb_phy);
> - if (ret)
> - goto put_usb3_hcd;
>   }
> +
>   xhci->shared_hcd->usb_phy = usb_phy;
> + xhci->shared_hcd->phy = phy;
> +
> + ret = xhci_plat_phy_init(hcd);
> + if (ret)
> + goto put_usb3_hcd;
> +
> + ret = xhci_plat_phy_init(xhci->shared_hcd);
> + if (ret)
> + goto disable_usb2_phy;
>  
>   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
>   if (ret)
> - goto disable_usb_phy;
> + goto disable_usb3_phy;
>  
>   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
>   if (ret)
> @@ -190,8 +245,11 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  dealloc_usb2_hcd:
>   usb_remove_hcd(hcd);
>  
> -disable_usb_phy:
> - usb_phy_shutdown(usb_phy);
> +disable_usb3_phy:
> + xhci_plat_phy_exit(xhci->shared_hcd);
> +
> +disable_usb2_phy:
> + xhci_plat_phy_exit(hcd);
>  
>  put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
> @@ -212,11 +270,11 @@ static int xhci_plat_remove(struct platform_device *dev)
>   struct clk *clk = xhci->clk;
>  
>   usb_remove_hcd(xhci->shared_hcd);
> - usb_phy_shutdown(xhci->shared_hcd->usb_phy);
> -
> - usb_remove_hcd(hcd);
> + xhci_plat_phy_exit(xhci->shared_hcd);
>   usb_put_hcd(xhci->shared_hcd);
>  
> + usb_remove_hcd(hcd);
> + xhci_plat_phy_exit(hcd);
>   clk_disable_unprepare(clk);
>   usb_put_hcd(hcd);
>  
> @@ -242,7 +300,8 @@ static int xhci_plat_suspend(struct device *dev)
>   if (ret)
>   return ret;
>  
> - usb_phy_shutdown(xhci->shared_hcd->usb_phy);
> + xhci_plat_phy_exit(xhci->shared_hcd);
> + xhci_plat_phy_exit(hcd);
>   clk_disable_unprepare(xhci->clk);
>  
>   return ret;
> @@ -258,7 +317,11 @@ static int xhci_plat_resume(struct device *dev)
>   if (ret)
>   return ret;
>  
> - ret = usb_phy_init(xhci->shared_hcd->usb_phy);
> + ret = xhci_plat_phy_init(hcd);
> + if (ret)

Re: [PATCH 7/7] usb: xhci: plat: add vbus regulator control

[Jisheng Zhang]

cc linux-usb@vger.kernel.org

On Fri, 4 Dec 2015 22:10:52 +0800
Jisheng Zhang  wrote:

> The Marvell BG4CT STB board has board level vbus control through gpio.
> This patch adds the vbus regulator control to support this board.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 39 ++-
>  drivers/usb/host/xhci.h  |  2 ++
>  2 files changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index bb972a6..9bf44569 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -116,6 +117,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   struct clk  *clk;
>   struct usb_phy  *usb_phy;
>   struct phy  *phy;
> + struct regulator*vbus;
>   int ret;
>   int irq;
>  
> @@ -179,14 +181,31 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  
>   device_wakeup_enable(hcd->self.controller);
>  
> + vbus = devm_regulator_get(>dev, "vbus");
> + if (PTR_ERR(vbus) == -ENODEV) {
> + vbus = NULL;
> + } else if (IS_ERR(vbus)) {
> + ret = PTR_ERR(vbus);
> + goto disable_clk;
> + } else {
> + ret = regulator_enable(vbus);
> + if (ret) {
> + dev_err(>dev,
> + "failed to enable usb vbus regulator: %d\n",
> + ret);
> + goto disable_clk;
> + }
> + }
> +
>   xhci = hcd_to_xhci(hcd);
>   xhci->clk = clk;
> + xhci->vbus = vbus;
>   xhci->main_hcd = hcd;
>   xhci->shared_hcd = usb_create_shared_hcd(driver, >dev,
>   dev_name(>dev), hcd);
>   if (!xhci->shared_hcd) {
>   ret = -ENOMEM;
> - goto disable_clk;
> + goto disable_vbus;
>   }
>  
>   if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
> @@ -254,6 +273,10 @@ disable_usb2_phy:
>  put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
>  
> +disable_vbus:
> + if (!vbus)
> + regulator_disable(vbus);
> +
>  disable_clk:
>   clk_disable_unprepare(clk);
>  
> @@ -268,6 +291,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>   struct usb_hcd  *hcd = platform_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>   struct clk *clk = xhci->clk;
> + struct regulator *vbus = xhci->vbus;
>  
>   usb_remove_hcd(xhci->shared_hcd);
>   xhci_plat_phy_exit(xhci->shared_hcd);
> @@ -278,6 +302,9 @@ static int xhci_plat_remove(struct platform_device *dev)
>   clk_disable_unprepare(clk);
>   usb_put_hcd(hcd);
>  
> + if (!vbus)
> + regulator_disable(vbus);
> +
>   return 0;
>  }
>  
> @@ -287,6 +314,7 @@ static int xhci_plat_suspend(struct device *dev)
>   int ret;
>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct regulator *vbus = xhci->vbus;
>  
>   /*
>* xhci_suspend() needs `do_wakeup` to know whether host is allowed
> @@ -303,6 +331,8 @@ static int xhci_plat_suspend(struct device *dev)
>   xhci_plat_phy_exit(xhci->shared_hcd);
>   xhci_plat_phy_exit(hcd);
>   clk_disable_unprepare(xhci->clk);
> + if (!vbus)
> + ret = regulator_disable(vbus);
>  
>   return ret;
>  }
> @@ -312,11 +342,18 @@ static int xhci_plat_resume(struct device *dev)
>   int ret;
>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct regulator *vbus = xhci->vbus;
>  
>   ret = clk_prepare_enable(xhci->clk);
>   if (ret)
>   return ret;
>  
> + if (!vbus) {
> + ret = regulator_enable(vbus);
> + if (ret)
> + return ret;
> + }
> +
>   ret = xhci_plat_phy_init(hcd);
>   if (ret)
>   return ret;
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 0b94512..1355d2a 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1541,6 +1541,8 @@ struct xhci_hcd {
>   struct msix_entry   *msix_entries;
>   /* optional clock */
>   struct clk  *clk;
> + /* optional regulator */
> + struct regulator*vbus;
>   /* data structures */
>   struct xhci_device_context_array *dcbaa;
>   struct xhci_ring*cmd_ring;

--
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

reading data at 500Hz

[Jose Colmenares]

Hi,

I'm using a USB Inertial Measurement Unit that theoretically produces data at 
500Hz. According to the timestamps on the data, indeed the data is being 
produced at 500Hz. But I'm getting it in burst, with an "efective" sampling 
rate of 6ms instead of 2ms. That is, 166Hz instead of 500hz.

I'm running ubuntu 14.04. I tried modifying the priority of the thread, but 
nothing changed.

The data is being read in polling mode. Every 2ms I try to read data from 
/dev/ttyACM0. A previous implementation was using the ioctl library to get the 
available data size, and after reaching a certain value the data was read. That 
code was going at 10Hz... 

I'm been trying to get my head around the polling rate of the usb driver, but 
all I find is related to USB's mouse polling rate. So I'm not sure how to apply 
that in my case. But it encourage me look further because it means that there 
may be a default usb polling rate somewhere!

We are using USB 2.0 (if it matters), ubuntu 14.04, I'm reading at 166Hz using 
a standard file descriptor. But I need to get the data faster. 500Hz would be 
amazing. 250Hz ( 4ms polling rate) would be enough.

The computer that will use the device (but I don't have access to all the time) 
has xenomai. Meaning very close to real time. But usually IO operations break 
the real time so this runs on a separate thread. I say this just in case is 
help full.

Cheers.



Jose Colmenares.
Software Engineer.
Dynamic Legged Systems, Advanced Robotics. 
Italian Institute of Technology.
+39 010 717 818 18--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] usb: xhci: fix config fail of FS hub behind a HS hub with MTT

[Mathias Nyman]

From: Chunfeng Yun 

if a full speed hub connects to a high speed hub which
supports MTT, the MTT field of its slot context will be set
to 1 when xHCI driver setups an xHCI virtual device in
xhci_setup_addressable_virt_dev(); once usb core fetch its
hub descriptor, and need to update the xHC's internal data
structures for the device, the HUB field of its slot context
will be set to 1 too, meanwhile MTT is also set before,
this will cause configure endpoint command fail, so in the
case, we should clear MTT to 0 for full speed hub according
to section 6.2.2

Signed-off-by: Chunfeng Yun 
Cc: stable 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index dfa44d3..3f91270 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4778,8 +4778,16 @@ int xhci_update_hub_device(struct usb_hcd *hcd, struct 
usb_device *hdev,
ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
slot_ctx = xhci_get_slot_ctx(xhci, config_cmd->in_ctx);
slot_ctx->dev_info |= cpu_to_le32(DEV_HUB);
+   /*
+* refer to section 6.2.2: MTT should be 0 for full speed hub,
+* but it may be already set to 1 when setup an xHCI virtual
+* device, so clear it anyway.
+*/
if (tt->multi)
slot_ctx->dev_info |= cpu_to_le32(DEV_MTT);
+   else if (hdev->speed == USB_SPEED_FULL)
+   slot_ctx->dev_info &= cpu_to_le32(~DEV_MTT);
+
if (xhci->hci_version > 0x95) {
xhci_dbg(xhci, "xHCI version %x needs hub "
"TT think time and number of ports\n",
-- 
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 0/2] xhci fixes for usb-linus

[Mathias Nyman]

Hi Greg

Only a couple small fixes for xhci, one fix allowing a FS hub to be
connected behind a HS hub, and one acpi variable memory leak.

-Mathias

Chunfeng Yun (1):
  usb: xhci: fix config fail of FS hub behind a HS hub with MTT

Mika Westerberg (1):
  xhci: Fix memory leak in xhci_pme_acpi_rtd3_enable()

 drivers/usb/host/xhci-pci.c | 8 ++--
 drivers/usb/host/xhci.c | 8 
 2 files changed, 14 insertions(+), 2 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 1/2] xhci: Fix memory leak in xhci_pme_acpi_rtd3_enable()

[Mathias Nyman]

From: Mika Westerberg 

There is a memory leak because acpi_evaluate_dsm() actually returns an
object which the caller is supposed to release. Fix this by calling
ACPI_FREE() for the returned object (this expands to kfree() so passing
NULL there is fine as well).

While there correct indentation in !CONFIG_ACPI case.

Signed-off-by: Mika Westerberg 
Cc: stable  # v4.2
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-pci.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 17f6897..c621090 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -188,10 +188,14 @@ static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
0xb7, 0x0c, 0x34, 0xac, 0x01, 0xe9, 0xbf, 0x45,
0xb7, 0xe6, 0x2b, 0x34, 0xec, 0x93, 0x1e, 0x23,
};
-   acpi_evaluate_dsm(ACPI_HANDLE(>dev), intel_dsm_uuid, 3, 1, NULL);
+   union acpi_object *obj;
+
+   obj = acpi_evaluate_dsm(ACPI_HANDLE(>dev), intel_dsm_uuid, 3, 1,
+   NULL);
+   ACPI_FREE(obj);
 }
 #else
-   static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev) { }
+static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev) { }
 #endif /* CONFIG_ACPI */
 
 /* called during probe() after chip reset completes */
-- 
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 2/7] usb: xhci: plat: attach the usb_phy to the correct hcd

[Jisheng Zhang]

cc linux-usb@vger.kernel.org

On Fri, 4 Dec 2015 22:10:47 +0800
Jisheng Zhang wrote:

> Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the
> usb_phy for usb3, but it attached the usb_phy to incorrect hcd. The
> xhci->shared_hcd is the hcd for usb3, this patch fixes this issue
> by attach the usb_phy to the xhci->shared_hcd.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index b566304..a8c465a 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -82,6 +82,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   struct resource *res;
>   struct usb_hcd  *hcd;
>   struct clk  *clk;
> + struct usb_phy  *usb_phy;
>   int ret;
>   int irq;
>  
> @@ -162,17 +163,18 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
>   xhci->shared_hcd->can_do_streams = 1;
>  
> - hcd->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> - if (IS_ERR(hcd->usb_phy)) {
> - ret = PTR_ERR(hcd->usb_phy);
> + usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> + if (IS_ERR(usb_phy)) {
> + ret = PTR_ERR(usb_phy);
>   if (ret == -EPROBE_DEFER)
>   goto put_usb3_hcd;
> - hcd->usb_phy = NULL;
> + usb_phy = NULL;
>   } else {
> - ret = usb_phy_init(hcd->usb_phy);
> + ret = usb_phy_init(usb_phy);
>   if (ret)
>   goto put_usb3_hcd;
>   }
> + xhci->shared_hcd->usb_phy = usb_phy;
>  
>   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
>   if (ret)
> @@ -189,7 +191,7 @@ dealloc_usb2_hcd:
>   usb_remove_hcd(hcd);
>  
>  disable_usb_phy:
> - usb_phy_shutdown(hcd->usb_phy);
> + usb_phy_shutdown(usb_phy);
>  
>  put_usb3_hcd:
>   usb_put_hcd(xhci->shared_hcd);
> @@ -211,7 +213,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>   struct clk *clk = xhci->clk;
>  
>   usb_remove_hcd(xhci->shared_hcd);
> - usb_phy_shutdown(hcd->usb_phy);
> + usb_phy_shutdown(xhci->shared_hcd->usb_phy);
>  
>   usb_remove_hcd(hcd);
>   usb_put_hcd(xhci->shared_hcd);

--
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/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

[Jisheng Zhang]

cc linux-usb@vger.kernel.org

On Fri, 4 Dec 2015 22:10:46 +0800
Jisheng Zhang wrote:

> Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds
> optional clk support, but it forgets to prepare/disable and
> enable/unprepare the clk in the resume/suspend path. This path fixes
> this issue by adding missing clk related calls.
> 
> Signed-off-by: Jisheng Zhang 
> Fixes: 4718c1774051 ("usb: host: xhci-plat: add clock support")
> ---
>  drivers/usb/host/xhci-plat.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 05647e6..b566304 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -226,6 +226,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>  #ifdef CONFIG_PM_SLEEP
>  static int xhci_plat_suspend(struct device *dev)
>  {
> + int ret;
>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>  
> @@ -237,14 +238,25 @@ static int xhci_plat_suspend(struct device *dev)
>* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
>* also applies to runtime suspend.
>*/
> - return xhci_suspend(xhci, device_may_wakeup(dev));
> + ret = xhci_suspend(xhci, device_may_wakeup(dev));
> + if (ret)
> + return ret;
> +
> + clk_disable_unprepare(xhci->clk);
> +
> + return ret;
>  }
>  
>  static int xhci_plat_resume(struct device *dev)
>  {
> + int ret;
>   struct usb_hcd  *hcd = dev_get_drvdata(dev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>  
> + ret = clk_prepare_enable(xhci->clk);
> + if (ret)
> + return ret;
> +
>   return xhci_resume(xhci, 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

Re: [PATCH 3/7] usb: xhci: plat: Fix suspend/resume when the optional usb_phy exists

[Jisheng Zhang]

cc linux-usb@vger.kernel.org

On Fri, 4 Dec 2015 22:10:48 +0800
Jisheng Zhang wrote:

> Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the
> usb_phy for usb3, but it forgets to shutdown/init the usb_phy in the
> suspend/resume path. This patch fixes this issue by adding missing
> usb_phy related calls.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/host/xhci-plat.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index a8c465a..cd49ae5 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -244,6 +244,7 @@ static int xhci_plat_suspend(struct device *dev)
>   if (ret)
>   return ret;
>  
> + usb_phy_shutdown(xhci->shared_hcd->usb_phy);
>   clk_disable_unprepare(xhci->clk);
>  
>   return ret;
> @@ -259,6 +260,10 @@ static int xhci_plat_resume(struct device *dev)
>   if (ret)
>   return ret;
>  
> + ret = usb_phy_init(xhci->shared_hcd->usb_phy);
> + if (ret)
> + return ret;
> +
>   return xhci_resume(xhci, 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

Re: [PATCH 0/7] usb: xhci-plat: support generic PHY and vbus regulator

[Jisheng Zhang]

cc linux-usb@vger.kernel.org

Sorry, I forget to do so. Will cc linux-usb in the future.

On Fri, 4 Dec 2015 22:10:45 +0800
Jisheng Zhang wrote:

> The Marvell BG4CT has xhci controller. This controller has two phys:
> one for usb2 and another for usb3. BG4CT boards have board level vbus
> control through gpio.
> 
> I plan to add the xhci support in two steps: first of all, add generic
> PHY and vbus regulator control support to the xhci-plat driver. Then
> add the usb2 and usb3 phy drivers, after that, we add the phy and xhci
> nodes in the dtsi.
> 
> This series takes the first step. The first three patches are bug fix.
> Then two clean up patches. The last two patches add generic PHY and
> vbus regulator control support.
> 
> 
> Jisheng Zhang (7):
>   usb: xhci: plat: Fix suspend/resume when the optional clk exists
>   usb: xhci: plat: attach the usb_phy to the correct hcd
>   usb: xhci: plat: Fix suspend/resume when the optional usb_phy exists
>   usb: xhci: plat: sort the headers in alphabetic order
>   usb: xhci: plat: Remove checks for optional clock in error/remove path
>   usb: xhci: plat: add generic PHY support
>   usb: xhci: plat: add vbus regulator control
> 
>  drivers/usb/host/xhci-plat.c | 159 
> +--
>  drivers/usb/host/xhci.h  |   2 +
>  2 files changed, 140 insertions(+), 21 deletions(-)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] usb: whci: replace dma_pool_alloc and memset with dma_pool_zalloc

[Geyslan G. Bem]

2015-12-04 13:44 GMT-03:00 Greg Kroah-Hartman :
> On Fri, Dec 04, 2015 at 01:33:18PM -0300, Geyslan G. Bem wrote:
>>
>> If you wish, you could list me subsystems in need of maintenance.
>
> I don't understand what you mean by this.

I meant that would be great to know which usb subsystems you do prefer
that I continue cleaning/refactoring or if any would be ok. :)


-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] usb: whci: replace dma_pool_alloc and memset with dma_pool_zalloc

[Greg Kroah-Hartman]

On Fri, Dec 04, 2015 at 02:13:35PM -0300, Geyslan G. Bem wrote:
> 2015-12-04 13:44 GMT-03:00 Greg Kroah-Hartman :
> > On Fri, Dec 04, 2015 at 01:33:18PM -0300, Geyslan G. Bem wrote:
> >>
> >> If you wish, you could list me subsystems in need of maintenance.
> >
> > I don't understand what you mean by this.
> 
> I meant that would be great to know which usb subsystems you do prefer
> that I continue cleaning/refactoring or if any would be ok. :)

Any part of the drivers/usb/* tree that you find needs cleanups and
fixes like these are great to do, please send patches for this, I'll
gladly take them.

thanks,

gre 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 2/3] usb: whci: replace dma_pool_alloc and memset with dma_pool_zalloc

[Greg Kroah-Hartman]

On Wed, Dec 02, 2015 at 05:43:11PM -0300, Geyslan G. Bem wrote:
> Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc.
> 
> Caught by coccinelle.
> 
> Signed-off-by: Geyslan G. Bem 
> ---
>  drivers/usb/host/whci/qset.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

This, and patch 3/3 were also already done by someone else :(
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: host: pci_quirks: fix memory leak, by adding iounmap

[Greg KH]

On Wed, Dec 02, 2015 at 10:51:37PM +0530, Saurabh Sengar wrote:
> added iounmap inorder to free memory mapped to base before returning
> 
> Signed-off-by: Saurabh Sengar 
> ---
> v2: changed logic a bit, because of recent patches pushed to usb-next
>  drivers/usb/host/pci-quirks.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 26cb8c8..2ac198c 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -992,7 +992,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>   if ((ext_cap_offset + sizeof(val)) > len) {
>   /* We're reading garbage from the controller */
>   dev_warn(>dev, "xHCI controller failing to respond");
> - return;
> + goto hc_init;

Are you sure this is correct?  That goto location then does a whole
bunch of things with the xhci controller that you just now determined is
failing to respond.  I can't take this as-is, sorry.

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: kernel panic while in interrupt handler

[Greg KH]

On Fri, Dec 04, 2015 at 05:29:30PM +0100, Enrico Mioso wrote:
> Hello guys.
> with my current hardware setup (EEE PC 701, 1GB RAM), I get occasional
> PANICs while in interrupt handlers. It seems I get these when dealing with
> USB devices: it happened seeminglsy while using my braille display some days
> ago, and repeated today when "hciconfig hci0 up"'ing a bluetooth dongle. I
> am not sure about this, and actually didn't manage to get some messages
> since the system crashes and I can't read usually. so this isn't meant to be
> a bug report of sort: just asking if someone else is experiencing similar
> troubles.

If you get a kernel oops message, that would be the best thing for us to
be able to help track down the issue.

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: kernel panic while in interrupt handler

[Enrico Mioso]

Thank you Greg. In case I am able, I'll provide more hints.
Thank you again,
Enrico
--
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] usb: host: pci_quirks: fix memory leak, by adding iounmap

[Saurabh Sengar]

added iounmap inorder to free memory mapped to base before returning

Signed-off-by: Saurabh Sengar 
---
v3: reverted to v1 logic, on top of usb-next branch
 drivers/usb/host/pci-quirks.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 26cb8c8..35af362 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -992,7 +992,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
if ((ext_cap_offset + sizeof(val)) > len) {
/* We're reading garbage from the controller */
dev_warn(>dev, "xHCI controller failing to respond");
-   return;
+   goto iounmap;
}
val = readl(base + ext_cap_offset);
 
@@ -1055,6 +1055,7 @@ hc_init:
 XHCI_MAX_HALT_USEC, val);
}
 
+iounmap:
iounmap(base);
 }
 
-- 
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/3] usb: uhci: replace dma_pool_alloc and memset with dma_pool_zalloc

[Greg Kroah-Hartman]

On Wed, Dec 02, 2015 at 05:41:44PM -0300, Geyslan G. Bem wrote:
> Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc.
> 
> Caught by coccinelle.
> 
> Signed-off-by: Geyslan G. Bem 
> ---
>  drivers/usb/host/uhci-q.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

This is already in my tree, it was done by someone else before you,
sorry about that :(

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 v2] usb: host: pci_quirks: fix memory leak, by adding iounmap

[Saurabh Sengar]

On 4 December 2015 at 21:53, Greg KH  wrote:
> On Wed, Dec 02, 2015 at 10:51:37PM +0530, Saurabh Sengar wrote:
>> added iounmap inorder to free memory mapped to base before returning
>>
>> Signed-off-by: Saurabh Sengar 
>> ---
>> v2: changed logic a bit, because of recent patches pushed to usb-next
>>  drivers/usb/host/pci-quirks.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
>> index 26cb8c8..2ac198c 100644
>> --- a/drivers/usb/host/pci-quirks.c
>> +++ b/drivers/usb/host/pci-quirks.c
>> @@ -992,7 +992,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>>   if ((ext_cap_offset + sizeof(val)) > len) {
>>   /* We're reading garbage from the controller */
>>   dev_warn(>dev, "xHCI controller failing to respond");
>> - return;
>> + goto hc_init;
>
> Are you sure this is correct?  That goto location then does a whole
> bunch of things with the xhci controller that you just now determined is
> failing to respond.  I can't take this as-is, sorry.
>
> greg k-h

Yes I agree, and in the first patch I didn't do this way.
But the latest patch which got introduced is doing "goto hc_init" at line 990

ext_cap_offset = xhci_find_next_ext_cap(base, 0, XHCI_EXT_CAPS_LEGACY);

if (!ext_cap_offset)
goto hc_init;

I think this is wrong too, may be I am wrong.

Any way I will send the first patch again on top of usb-next as v3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] usb: whci: replace dma_pool_alloc and memset with dma_pool_zalloc

[Greg Kroah-Hartman]

On Fri, Dec 04, 2015 at 01:33:18PM -0300, Geyslan G. Bem wrote:
> 
> If you wish, you could list me subsystems in need of maintenance.

I don't understand what you mean by this.
--
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

kernel panic while in interrupt handler

[Enrico Mioso]

Hello guys.
with my current hardware setup (EEE PC 701, 1GB RAM), I get occasional PANICs 
while in interrupt handlers. It seems I get these when dealing with USB 
devices: it happened seeminglsy while using my braille display some days ago, 
and repeated today when "hciconfig hci0 up"'ing a bluetooth dongle. I am not 
sure about this, and actually didn't manage to get some messages since the 
system crashes and I can't read usually. 
so this isn't meant to be a bug report of sort: just asking if someone else is 
experiencing similar troubles.


Thank you all,
Enrico


dmesg:
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.0-rc3taxidriver+ (mrkiko@eeeinsomma) (gcc 
version 5.2.0 (GCC) ) #6 Fri Dec 4 16:44:41 CET 2015
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] Disabled fast string operations
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x3f77] usable
[0.00] BIOS-e820: [mem 0x3f78-0x3f78] ACPI data
[0.00] BIOS-e820: [mem 0x3f79-0x3f7c] ACPI NVS
[0.00] BIOS-e820: [mem 0x3f7d-0x3f7ddfff] reserved
[0.00] BIOS-e820: [mem 0x3f7e-0x3f7f] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xfff8-0x] reserved
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] SMBIOS 2.5 present.
[0.00] DMI: ASUSTeK Computer INC. 701/701, BIOS 100105/04/2008
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x3f780 max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-D uncachable
[0.00]   E-E write-through
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask FC000 write-back
[0.00]   1 base 03F80 mask FFF80 uncachable
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: PAT not supported by CPU.
[0.00] initial memory mapped: [mem 0x-0x1dbf]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] BRK [0x1d6ae000, 0x1d6aefff] PGTABLE
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000FBE60 14 (v00 ACPIAM)
[0.00] ACPI: RSDT 0x3F78 34 (v01 A M I  OEMRSDT  
05000804 MSFT 0097)
[0.00] ACPI: FACP 0x3F780200 81 (v01 A M I  OEMFACP  
05000804 MSFT 0097)
[0.00] ACPI: DSDT 0x3F780400 005F61 (v01 A0797  A0797000 
 INTL 20051117)
[0.00] ACPI: FACS 0x3F79 40
[0.00] ACPI: APIC 0x3F780390 68 (v01 A M I  OEMAPIC  
05000804 MSFT 0097)
[0.00] ACPI: OEMB 0x3F790040 46 (v01 A M I  AMI_OEM  
05000804 MSFT 0097)
[0.00] ACPI: MCFG 0x3F786370 3C (v01 A M I  OEMMCFG  
05000804 MSFT 0097)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] 127MB HIGHMEM available.
[0.00] 887MB LOWMEM available.
[0.00]   mapped low ram: 0 - 377fe000
[0.00]   low ram: 0 - 377fe000
[0.00] BRK [0x1d6af000, 0x1d6a] PGTABLE
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x1000-0x377fdfff]
[0.00]   HighMem  [mem 0x377fe000-0x3f77]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x3f77]
[0.00] Initmem setup node 0 [mem 0x1000-0x3f77]
[0.00] On node 0 totalpages: 259870
[0.00] free_area_init_node: node 0, pgdat dd57e0e0, node_mem_map 
f700e020
[0.00]   Normal zone: 1776 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 227228 pages, LIFO batch:31
[0.00]   HighMem zone: 32642 pages, LIFO batch:7
[0.00] Using APIC driver 

Re: [PATCH 2/3] usb: whci: replace dma_pool_alloc and memset with dma_pool_zalloc

[Geyslan G. Bem]

2015-12-04 13:25 GMT-03:00 Greg Kroah-Hartman :
> On Wed, Dec 02, 2015 at 05:43:11PM -0300, Geyslan G. Bem wrote:
>> Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc.
>>
>> Caught by coccinelle.
>>
>> Signed-off-by: Geyslan G. Bem 
>> ---
>>  drivers/usb/host/whci/qset.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> This, and patch 3/3 were also already done by someone else :(

I see. No problem at all.

If you wish, you could list me subsystems in need of maintenance.

Thanks.

-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Infrastructure for zerocopy I/O

[Alan Stern]

On Fri, 4 Dec 2015, Steinar H. Gunderson wrote:

> On Fri, Dec 04, 2015 at 01:29:05AM +0100, Steinar H. Gunderson wrote:
> > I must be doing something wrong, because I don't seem to get any frames
> > from my video capture, and when I close the application, I get a slowpath
> > warning:
> 
> OK, the slowpath warning is a red herring -- it's just because I do the free
> under a spinlock, and I can fix that.
> 
> There's still something that causes me to not get any frames, though.

What does usbmon show?  (See Documentation/usb/usbmon.txt.)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] usb: coccinelle and checkpatch cleanup

[Geyslan G. Bem]

While applying the "scripts/coccinelle/misc/compare_const_fl.cocci" in
usb/host/ tree I found files that deserve almost a full cleanup (very
wrong coding style). Eg. drivers/usb/host/ohci-dbg.c

Can I do a full cleaning or only coccinelle patches?

-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel panic while in interrupt handler

[Peter Stuge]

Hi Enrico,

Enrico Mioso wrote:
> In case I am able, I'll provide more hints.

There are a few ways to get the kernel oops output off the computer
without copying off the screen; netconsole, a USB debug device, and
last but not least photographing the computer screen.

One problem with using a USB debug device is of course that an oops
in the USB subsystem may stop a USB debug device from functioning.

I would suggest trying netconsole with the builtin network port.


//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] net: qmi_wwan: MDM9x30 support

[David Miller]

From: Bjørn Mork 
Date: Thu,  3 Dec 2015 19:24:17 +0100

> We add new device IDs all the time, often without any testing on
> actual hardware. This is usually OK as long as the device is similar
> to already supported devices, using the same chipset and firmware
> basis.  But the Sierra Wireless MC7455 is an example of a new chipset
> generation. Adding it based on assumed similarity with its ancestors
> proved too optimistic.
> 
> This series adds the missing bits and pieces necessary to support LTE
> Advanced modems based on the Qualcomm MDM9x30 chipset. A big thanks to
> Sierra Wireless for providing MC7455 samples for testing

Series applied to net-next, thanks a lot.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling

[chunfeng yun]

Hi,
On Fri, 2015-12-04 at 16:24 +0300, Sergei Shtylyov wrote:
> Hello.
> 
> Sorry for the grammar nitpicking but since it's in the comments, I felt 
> the necessity to comment.
> 
> On 12/4/2015 5:40 AM, Chunfeng Yun wrote:
> 
> > when ip fail to enter sleep mode, register access protection will
> 
> Fails.
> 
> > be disabed, at the same time if all clocks are disabled, access
>   ^^^ disabled
> 
> > register will hang up AHB bus.
> > the common case causes ip sleep fail is that after all ports enter
> 
> Failure.
> 
> > U3 but before ip enters sleep mode, a port receives a resume
> > signal('K'). this will happens when such as clicks mouse to try to
> > do remote wakeup to stop system enter suspend.
> 
> Wake up.
> 
> > so stop polling roothubs to avoid access xHCI register on bus
> 
> Root hubs. Accessing.
> 
> > suspend, and restart it when bus resume.
> 
> Resumes. Or "is resumed", maybe?
> 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >   drivers/usb/host/xhci-mtk.c | 23 +++
> >   1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > index c9ab6a4..38635fb 100644
> > --- a/drivers/usb/host/xhci-mtk.c
> > +++ b/drivers/usb/host/xhci-mtk.c
> > @@ -696,9 +696,24 @@ static int xhci_mtk_remove(struct platform_device *dev)
> >   }
> >
> >   #ifdef CONFIG_PM_SLEEP
> > +/*
> > + * if ip sleep fail, and all clocks are disabled, access register will hang
> 
> Fails.
> 
> > + * AHB bus, so stop poll roothubs to avoid regs access on bus suspend.
> 
> Polling.
> 
> > + * and no need to check whether ip sleep fail or not; this will cause SPM 
> > to
> 
> Failed.
> 
> > + * wakeup system immediately after system suspend complete if ip sleep
> 
> Wake up.
> 
> > + * fail, it is what we wanted.
> 
> Fails.
> 

I do need to pay more attention to the grammar from now on.

Thanks a lot

> > + */
> [...]
> 
> MBR, 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

[PATCH v2] usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling

[Chunfeng Yun]

when ip fails to enter sleep mode, register access protection will
be disabled, at the same time if all clocks are disabled, access
register will hang up AHB bus.
the common case causes ip sleep failure is that after all ports
enter U3 but before ip enters sleep mode, a port receives a resume
signal('K'). this will happens when such as clicks mouse to try to
do remote-wakeup to stop system enter suspend.
so stop polling root hubs to avoid access xHCI register on bus
suspend, and restart it when bus resumes.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index c9ab6a4..9532f5a 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -696,9 +696,24 @@ static int xhci_mtk_remove(struct platform_device *dev)
 }
 
 #ifdef CONFIG_PM_SLEEP
+/*
+ * if ip sleep fails, and all clocks are disabled, access register will hang
+ * AHB bus, so stop polling roothubs to avoid regs access on bus suspend.
+ * and no need to check whether ip sleep failed or not; this will cause SPM
+ * to wake up system immediately after system suspend complete if ip sleep
+ * fails, it is what we wanted.
+ */
 static int xhci_mtk_suspend(struct device *dev)
 {
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+   struct usb_hcd *hcd = mtk->hcd;
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   xhci_dbg(xhci, "%s: stop port polling\n", __func__);
+   clear_bit(HCD_FLAG_POLL_RH, >flags);
+   del_timer_sync(>rh_timer);
+   clear_bit(HCD_FLAG_POLL_RH, >shared_hcd->flags);
+   del_timer_sync(>shared_hcd->rh_timer);
 
xhci_mtk_host_disable(mtk);
xhci_mtk_phy_power_off(mtk);
@@ -710,11 +725,19 @@ static int xhci_mtk_suspend(struct device *dev)
 static int xhci_mtk_resume(struct device *dev)
 {
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+   struct usb_hcd *hcd = mtk->hcd;
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
 
usb_wakeup_disable(mtk);
xhci_mtk_clks_enable(mtk);
xhci_mtk_phy_power_on(mtk);
xhci_mtk_host_enable(mtk);
+
+   xhci_dbg(xhci, "%s: restart port polling\n", __func__);
+   set_bit(HCD_FLAG_POLL_RH, >flags);
+   usb_hcd_poll_rh_status(hcd);
+   set_bit(HCD_FLAG_POLL_RH, >shared_hcd->flags);
+   usb_hcd_poll_rh_status(xhci->shared_hcd);
return 0;
 }
 
-- 
1.8.1.1.dirty

--
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: [TESTPATCH v2] xhci: fix usb2 resume timing and races.

[Daniel J Blueman]

On 1 December 2015 at 16:26, Mathias Nyman
 wrote:
> usb2 ports need to signal resume for 20ms before moving to U0 state.
> Both device and host can initiate resume.
>
> On host initated resume port is set to resume state, sleep 20ms,
> and finally set port to U0 state.
>
> On device initated resume a port status interrupt with a port in resume
> state in issued. The interrupt handler tags a resume_done[port]
> timestamp with current time + 20ms, and kick roothub timer.
> Root hub timer requests for port status, finds the port in resume state,
> checks if resume_done[port] timestamp passed, and set port to U0 state.
>
> There are a few issues with this approach,
> 1. A host initated resume will also generate a resume event, the event
>handler will find the port in resume state, believe it's a device
>initated and act accordingly.
>
> 2. A port status request might cut the 20ms resume signalling short if a
>get_port_status request is handled during the 20ms host resume.
>The port will be found in resume state. The timestamp is not set leading
>to time_after_eq(jiffoes, timestamp) returning true, as timestamp = 0.
>get_port_status will proceed with moving the port to U0.
>
> 3. If an error, or anything else happends to the port during device
>initated 20ms resume signalling it will leave all device resume
>parameters hanging uncleared preventing further resume.
>
> Fix this by using the existing resuming_ports bitfield to indicate if
> resume signalling timing is taken care of.
> Also check if the resume_done[port] is set  before using it in time
> comparison. Also clear out any resume signalling related variables if port
> is not in U0 or Resume state.
>
> v2. fix parentheses when checking for uncleared resume variables.
> we want: if ((unclear1 OR unclear2 ) AND !in_resume AND !in_U3) { .. }
>
> Signed-off-by: Mathias Nyman 

Excellent; this correctly prevents the cyclic chain of suspend
attempts, resolving the issue.

Tested-by: Daniel J Blueman 

Thanks Mathias!
  Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] usb: whci: replace dma_pool_alloc and memset with dma_pool_zalloc

[Geyslan G. Bem]

2015-12-04 14:18 GMT-03:00 Greg Kroah-Hartman :
> On Fri, Dec 04, 2015 at 02:13:35PM -0300, Geyslan G. Bem wrote:
>> 2015-12-04 13:44 GMT-03:00 Greg Kroah-Hartman :
>> > On Fri, Dec 04, 2015 at 01:33:18PM -0300, Geyslan G. Bem wrote:
>> >>
>> >> If you wish, you could list me subsystems in need of maintenance.
>> >
>> > I don't understand what you mean by this.
>>
>> I meant that would be great to know which usb subsystems you do prefer
>> that I continue cleaning/refactoring or if any would be ok. :)
>
> Any part of the drivers/usb/* tree that you find needs cleanups and
> fixes like these are great to do, please send patches for this, I'll
> gladly take them.

Nice, I'll indeed.

Thanks.
>
> thanks,
>
> gre k-h



-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html