[PATCH v2] ohci-pci: add qemu quirk
On a loaded virtualization host (dozen guests booting at the same time)
it may happen that the ohci controller emulation doesn't manage to do
timely frame processing, with the result that the io watchdog fires and
considers the controller being dead, even though it's only the emulation
being unusual slow due to the load peak.
So, add a quirk for qemu and don't use the watchdog in case we figure we
are running on emulated ohci. The virtual ohci controller masquerades
as apple ohci controller, but we can identify it by subsystem id.
Signed-off-by: Gerd Hoffmann
---
drivers/usb/host/ohci-hcd.c | 3 ++-
drivers/usb/host/ohci-pci.c | 16
drivers/usb/host/ohci.h | 1 +
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index b6daf2e..5f81a2b 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -231,7 +231,8 @@ static int ohci_urb_enqueue (
/* Start up the I/O watchdog timer, if it's not running */
if (!timer_pending(&ohci->io_watchdog) &&
- list_empty(&ohci->eds_in_use)) {
+ list_empty(&ohci->eds_in_use) &&
+ !(ohci->flags & OHCI_QUIRK_QEMU)) {
ohci->prev_frame_no = ohci_frame_no(ohci);
mod_timer(&ohci->io_watchdog,
jiffies + IO_WATCHDOG_DELAY);
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index bb15096..a84aebe 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -164,6 +164,15 @@ static int ohci_quirk_amd700(struct usb_hcd *hcd)
return 0;
}
+static int ohci_quirk_qemu(struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+
+ ohci->flags |= OHCI_QUIRK_QEMU;
+ ohci_dbg(ohci, "enabled qemu quirk\n");
+ return 0;
+}
+
/* List of quirks for OHCI */
static const struct pci_device_id ohci_pci_quirks[] = {
{
@@ -214,6 +223,13 @@ static int ohci_quirk_amd700(struct usb_hcd *hcd)
PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
+ {
+ .vendor = PCI_VENDOR_ID_APPLE,
+ .device = 0x003f,
+ .subvendor = PCI_SUBVENDOR_ID_REDHAT_QUMRANET,
+ .subdevice = PCI_SUBDEVICE_ID_QEMU,
+ .driver_data= (unsigned long)ohci_quirk_qemu,
+ },
/* FIXME for some of the early AMD 760 southbridges, OHCI
* won't work at all. blacklist them.
diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index 37f1725..a51b189 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -418,6 +418,7 @@ struct ohci_hcd {
#defineOHCI_QUIRK_AMD_PLL 0x200 /* AMD PLL
quirk*/
#defineOHCI_QUIRK_AMD_PREFETCH 0x400 /* pre-fetch
for ISO transfer */
#defineOHCI_QUIRK_GLOBAL_SUSPEND 0x800 /* must suspend
ports */
+#defineOHCI_QUIRK_QEMU 0x1000 /* relax timing
expectations */
// there are also chip quirks/bugs in init logic
--
1.8.3.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 net 2/2] r8152: fix the rx early size of RTL8153
revert commit a59e6d815226 ("r8152: correct the rx early size") and
fix the rx early size as
(rx buffer size - rx packet size - rx desc size - alignment) / 4
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3a892fa..800be78 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -32,7 +32,7 @@
#define NETNEXT_VERSION"08"
/* Information for net */
-#define NET_VERSION"8"
+#define NET_VERSION"9"
#define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
#define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -501,6 +501,8 @@ enum rtl_register_content {
#define RTL8153_RMSRTL8153_MAX_PACKET
#define RTL8152_TX_TIMEOUT (5 * HZ)
#define RTL8152_NAPI_WEIGHT64
+#define rx_reserved_size(x)((x) + VLAN_ETH_HLEN + CRC_SIZE + \
+sizeof(struct rx_desc) + RX_ALIGN)
/* rtl8152 flags */
enum rtl8152_flags {
@@ -2252,8 +2254,7 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
static void r8153_set_rx_early_size(struct r8152 *tp)
{
- u32 mtu = tp->netdev->mtu;
- u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 8;
+ u32 ocp_data = (agg_buf_sz - rx_reserved_size(tp->netdev->mtu)) / 4;
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data);
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 1/2] r8152: set the RMS of RTL8153 according to the mtu
Set the received maximum size (RMS) according to the mtu size. It is
unnecessary to receive a packet which is more than the size we could
transmit. Besides, this could let the rx buffer be used effectively.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 986243c..3a892fa 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2898,7 +2898,8 @@ static void r8153_first_init(struct r8152 *tp)
rtl_rx_vlan_en(tp, tp->netdev->features & NETIF_F_HW_VLAN_CTAG_RX);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, RTL8153_RMS);
+ ocp_data = tp->netdev->mtu + VLAN_ETH_HLEN + CRC_SIZE;
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, ocp_data);
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_MTPS, MTPS_JUMBO);
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_TCR0);
@@ -2950,7 +2951,8 @@ static void r8153_enter_oob(struct r8152 *tp)
usleep_range(1000, 2000);
}
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, RTL8153_RMS);
+ ocp_data = tp->netdev->mtu + VLAN_ETH_HLEN + CRC_SIZE;
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, ocp_data);
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_TEREDO_CFG);
ocp_data &= ~TEREDO_WAKE_MASK;
@@ -4200,8 +4202,14 @@ static int rtl8152_change_mtu(struct net_device *dev,
int new_mtu)
dev->mtu = new_mtu;
- if (netif_running(dev) && netif_carrier_ok(dev))
- r8153_set_rx_early_size(tp);
+ if (netif_running(dev)) {
+ u32 rms = new_mtu + VLAN_ETH_HLEN + CRC_SIZE;
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, rms);
+
+ if (netif_carrier_ok(dev))
+ r8153_set_rx_early_size(tp);
+ }
mutex_unlock(&tp->control);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 0/2] r8152: fix the rx settings of RTL8153
The RMS and the rx early size should base on the same rx size. However, the RMS is set to 9K bytes now and the rx early depends on mtu. For using the rx buffer effectively, sync the two settings according to the mtu. Hayes Wang (2): r8152: set the RMS of RTL8153 according to the mtu r8152: fix the rx early size of RTL8153 drivers/net/usb/r8152.c | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: phy: Introduce one extcon device into usb phy
Hi, On 19 March 2017 at 19:42, kbuild test robot wrote: > Hi Baolin, > > [auto build test ERROR on balbi-usb/next] > [also build test ERROR on v4.11-rc2 next-20170310] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baolin-Wang/usb-phy-Introduce-one-extcon-device-into-usb-phy/20170319-175509 > base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next > config: i386-randconfig-i1-201712 (attached as .config) > compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4 > reproduce: > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > >drivers/built-in.o: In function `usb_add_extcon': >>> phy.c:(.text+0x231580): undefined reference to `extcon_get_edev_by_phandle' >>> phy.c:(.text+0x2315d0): undefined reference to >>> `devm_extcon_register_notifier' >phy.c:(.text+0x231629): undefined reference to > `devm_extcon_register_notifier' I am not sure how the errors were happened, since we will always select EXTCON if we have selected USB_PHY, moreover we have included the "linux/extcon.h" in phy.h file. -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: dummy_hcd: Fix wrong port status macros in dummy_hub_control()
Hello!
On 3/19/2017 11:23 PM, Yuyang Du wrote:
This fixes the commit: 1cd8fd2887e162ad3d06715 (usb: gadget: dummy_hcd:
add SuperSpeed support).
It should be quoted as commit 1cd8fd2887e1 ("usb: gadget: dummy_hcd:
> add SuperSpeed support"). See Documentation/process/submitting-patches.rst,
section 2.
Signed-off-by: Yuyang Du
[...]
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: Oops with dwc3 in device mode and functionfs
Hi, Andy Shevchenko writes: > On Sat, 2017-01-07 at 04:07 +, Vincent Pelletier wrote: >> On Fri, 6 Jan 2017 15:21:17 +, Vincent Pelletier >> wrote: >> > The next issue is that often (>9 times out of 10) the dwc3 fails to >> > respond to the SET_CONFIGURATION standard request. As a result, only >> > EP0 works. >> >> I captured a successful enumeration, there are also corrupted pids: > > Can you check my latest snapshot? > > It has been discovered that ep1 and ep8 are not usable for USB (tracing > related stuff). Felipe did a quick hack for that. yeah, I have been writing a functionfs "driver" myself to test stuff out. It's still pretty early but at least enumeration is rather solid. -- balbi -- 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: gadget: Correct usb EP argument for BOT status request
This patch corrects the argument in usb_ep_free_request as it is mistakenly set to ep_out. It should be ep_in for status request. Signed-off-by: Manish Narani --- drivers/usb/gadget/function/f_tcm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c index d235113..a82e2bd 100644 --- a/drivers/usb/gadget/function/f_tcm.c +++ b/drivers/usb/gadget/function/f_tcm.c @@ -373,7 +373,7 @@ static void bot_cleanup_old_alt(struct f_uas *fu) usb_ep_free_request(fu->ep_in, fu->bot_req_in); usb_ep_free_request(fu->ep_out, fu->bot_req_out); usb_ep_free_request(fu->ep_out, fu->cmd.req); - usb_ep_free_request(fu->ep_out, fu->bot_status.req); + usb_ep_free_request(fu->ep_in, fu->bot_status.req); kfree(fu->cmd.buf); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] phy: Move ULPI phy header out of drivers to include path
Although ULPI phy is currently being used by tusb1210,
there can be other consumers too in future. So move this
to the includes path for phy.
Signed-off-by: Vivek Gautam
Cc: Stephen Boyd
Cc: Heikki Krogerus
Cc: Kishon Vijay Abraham I
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
Changes since v3:
- Removed qcom phy changes, since patch - 1/3 addressed that now.
Changes since v2:
- Updated the location for this header in drivers using it.
drivers/phy/phy-tusb1210.c| 3 +--
{drivers => include/linux}/phy/ulpi_phy.h | 0
2 files changed, 1 insertion(+), 2 deletions(-)
rename {drivers => include/linux}/phy/ulpi_phy.h (100%)
diff --git a/drivers/phy/phy-tusb1210.c b/drivers/phy/phy-tusb1210.c
index 4f6d5e71507d..bb3fb031c478 100644
--- a/drivers/phy/phy-tusb1210.c
+++ b/drivers/phy/phy-tusb1210.c
@@ -12,8 +12,7 @@
#include
#include
#include
-
-#include "ulpi_phy.h"
+#include
#define TUSB1210_VENDOR_SPECIFIC2 0x80
#define TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT 0
diff --git a/drivers/phy/ulpi_phy.h b/include/linux/phy/ulpi_phy.h
similarity index 100%
rename from drivers/phy/ulpi_phy.h
rename to include/linux/phy/ulpi_phy.h
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v4 3/3] phy: Group vendor specific phy drivers
Adding vendor specific directories in phy to group
phy drivers under their respective vendor umbrella.
Also updated the MAINTAINERS file to reflect the correct
directory structure for phy drivers.
Signed-off-by: Vivek Gautam
Acked-by: Heiko Stuebner
Acked-by: Viresh Kumar
Acked-by: Krzysztof Kozlowski
Acked-by: Yoshihiro Shimoda
Reviewed-by: Jaehoon Chung
Cc: Kishon Vijay Abraham I
Cc: David S. Miller
Cc: Geert Uytterhoeven
Cc: Yoshihiro Shimoda
Cc: Guenter Roeck
Cc: Heiko Stuebner
Cc: Viresh Kumar
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Sylwester Nawrocki
Cc: Krzysztof Kozlowski
Cc: Jaehoon Chung
Cc: Stephen Boyd
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
Changes since v3:
- Added 'Acked-by' and 'Reviewed by' tags received for this patch.
- No functional change.
Changes since v2:
- Rebased on linux-phy/next.
- Took care of drivers added/removed for each vendors since v2.
- Updated the 'Signed-off-by' tag with my current email id.
Changes from v1:
- Updated the MAINTAINERS file to reflect the same change
in directory structure.
- Removed PHY_PLAT config as pointed out by Kishon.
So we don't require the second patch in the v1 of this series:
[PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency
- Renamed sunxi --> allwinner; rcar --> renesas.
- Fixed error coming with qcom Makefile.
* Build tested multi_v7_defconfig.
* Build tested arm64 defconfig with all the involved configs enabled.
MAINTAINERS| 18 +-
drivers/phy/Kconfig| 471 +
drivers/phy/Makefile | 67 +--
drivers/phy/allwinner/Kconfig | 31 ++
drivers/phy/allwinner/Makefile | 2 +
drivers/phy/{ => allwinner}/phy-sun4i-usb.c| 0
drivers/phy/{ => allwinner}/phy-sun9i-usb.c| 0
drivers/phy/broadcom/Kconfig | 64 +++
drivers/phy/broadcom/Makefile | 7 +
drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c | 0
drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c | 0
drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c | 0
drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c | 0
drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c | 0
drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c | 0
drivers/phy/{ => broadcom}/phy-brcm-sata.c | 0
drivers/phy/hisilicon/Kconfig | 20 +
drivers/phy/hisilicon/Makefile | 2 +
drivers/phy/{ => hisilicon}/phy-hi6220-usb.c | 0
drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c | 0
drivers/phy/marvell/Kconfig| 50 +++
drivers/phy/marvell/Makefile | 6 +
drivers/phy/{ => marvell}/phy-armada375-usb2.c | 0
drivers/phy/{ => marvell}/phy-berlin-sata.c| 0
drivers/phy/{ => marvell}/phy-berlin-usb.c | 0
drivers/phy/{ => marvell}/phy-mvebu-sata.c | 0
drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c | 0
drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c | 0
drivers/phy/qualcomm/Kconfig | 38 ++
drivers/phy/qualcomm/Makefile | 7 +
drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h| 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c | 0
drivers/phy/renesas/Kconfig| 17 +
drivers/phy/renesas/Makefile | 2 +
drivers/phy/{ => renesas}/phy-rcar-gen2.c | 0
drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c | 0
drivers/phy/rockchip/Kconfig | 51 +++
drivers/phy/rockchip/Makefile | 6 +
drivers/phy/{ => rockchip}/phy-rockchip-dp.c | 0
drivers/phy/{ => rockchip}/phy-rockchip-emmc.c | 0
.../phy/{ => rockchip}/phy-rockchip-inno-usb2.c| 0
drivers/phy/{ => rockchip}/phy-rockchip-pcie.c | 0
drivers/phy/{ => rockchip}/phy-rockchip-typec.c| 0
drivers/phy/{ => rockchip}/phy-rockchip-usb.c | 0
drivers/phy/samsung/Kconfig| 96 +
drivers/phy/samsung/Makefile | 11 +
drivers/phy/{ => samsung}/phy-exynos-dp-video.c| 0
drivers/phy/{ => samsung}/phy
[PATCH v4 0/3] phy: Group phy drivers based on vendor listing
This is the next version to an earlier posted series [1].
Missed Cc'ing the first patch of the previous series [1] to lkml.
Posting out this series now after addressing comments
and after adding the received 'Acked-by' and 'Reviewed-by'
tags.
This series is based on linux-phy/next branch.
[1] https://www.spinics.net/lists/arm-kernel/msg568370.html
Signed-off-by: Vivek Gautam
Cc: Kishon Vijay Abraham I
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
--
Vivek Gautam (3):
phy: qcom-usb: Remove unused ulpi phy header
phy: Move ULPI phy header out of drivers to include path
phy: Group vendor specific phy drivers
MAINTAINERS| 18 +-
drivers/phy/Kconfig| 471 +
drivers/phy/Makefile | 67 +--
drivers/phy/allwinner/Kconfig | 31 ++
drivers/phy/allwinner/Makefile | 2 +
drivers/phy/{ => allwinner}/phy-sun4i-usb.c| 0
drivers/phy/{ => allwinner}/phy-sun9i-usb.c| 0
drivers/phy/broadcom/Kconfig | 64 +++
drivers/phy/broadcom/Makefile | 7 +
drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c | 0
drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c | 0
drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c | 0
drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c | 0
drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c | 0
drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c | 0
drivers/phy/{ => broadcom}/phy-brcm-sata.c | 0
drivers/phy/hisilicon/Kconfig | 20 +
drivers/phy/hisilicon/Makefile | 2 +
drivers/phy/{ => hisilicon}/phy-hi6220-usb.c | 0
drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c | 0
drivers/phy/marvell/Kconfig| 50 +++
drivers/phy/marvell/Makefile | 6 +
drivers/phy/{ => marvell}/phy-armada375-usb2.c | 0
drivers/phy/{ => marvell}/phy-berlin-sata.c| 0
drivers/phy/{ => marvell}/phy-berlin-usb.c | 0
drivers/phy/{ => marvell}/phy-mvebu-sata.c | 0
drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c | 0
drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c | 0
drivers/phy/qualcomm/Kconfig | 38 ++
drivers/phy/qualcomm/Makefile | 7 +
drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h| 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h | 0
drivers/phy/{ => qualcomm}/phy-qcom-ufs.c | 0
drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c | 2 -
drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c | 2 -
drivers/phy/renesas/Kconfig| 17 +
drivers/phy/renesas/Makefile | 2 +
drivers/phy/{ => renesas}/phy-rcar-gen2.c | 0
drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c | 0
drivers/phy/rockchip/Kconfig | 51 +++
drivers/phy/rockchip/Makefile | 6 +
drivers/phy/{ => rockchip}/phy-rockchip-dp.c | 0
drivers/phy/{ => rockchip}/phy-rockchip-emmc.c | 0
.../phy/{ => rockchip}/phy-rockchip-inno-usb2.c| 0
drivers/phy/{ => rockchip}/phy-rockchip-pcie.c | 0
drivers/phy/{ => rockchip}/phy-rockchip-typec.c| 0
drivers/phy/{ => rockchip}/phy-rockchip-usb.c | 0
drivers/phy/samsung/Kconfig| 96 +
drivers/phy/samsung/Makefile | 11 +
drivers/phy/{ => samsung}/phy-exynos-dp-video.c| 0
drivers/phy/{ => samsung}/phy-exynos-mipi-video.c | 0
drivers/phy/{ => samsung}/phy-exynos-pcie.c| 0
drivers/phy/{ => samsung}/phy-exynos4210-usb2.c| 0
drivers/phy/{ => samsung}/phy-exynos4x12-usb2.c| 0
drivers/phy/{ => samsung}/phy-exynos5-usbdrd.c | 0
drivers/phy/{ => samsung}/phy-exynos5250-sata.c| 0
drivers/phy/{ => samsung}/phy-exynos5250-usb2.c| 0
drivers/phy/{ => samsung}/phy-s5pv210-usb2.c | 0
drivers/phy/{ => samsung}/phy-samsung-usb2.c | 0
drivers/phy/{ => samsung}/phy-samsung-usb2.h | 0
drivers/phy/st/Kconfig | 33 ++
drivers/phy/st/Makefile| 4 +
drivers/phy/{ => st}/phy-miphy28lp.c | 0
drivers/phy/{ => st}/phy-spear1310-miphy.c | 0
drivers/phy/{ => st}/phy-spear1340-miphy.c | 0
drivers/phy/{ => st}/phy-stih407-usb.c | 0
drivers/phy/ti/Kconfig | 78
drivers/phy/ti/Ma
[PATCH v4 1/3] phy: qcom-usb: Remove unused ulpi phy header
Ulpi phy header is not used for anything. Remove the same from qcom-hs and qcom-hsic phy drivers. Signed-off-by: Vivek Gautam Suggested-by: Stephen Boyd Cc: Kishon Vijay Abraham I Cc: linux-arm-ker...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-usb@vger.kernel.org --- - New patch added in the series. Removing headers as per Stephen's suggestion. drivers/phy/phy-qcom-usb-hs.c | 2 -- drivers/phy/phy-qcom-usb-hsic.c | 2 -- 2 files changed, 4 deletions(-) diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c index 94dfbfd739c3..43704f4f23e9 100644 --- a/drivers/phy/phy-qcom-usb-hs.c +++ b/drivers/phy/phy-qcom-usb-hs.c @@ -15,8 +15,6 @@ #include #include -#include "ulpi_phy.h" - #define ULPI_PWR_CLK_MNG_REG 0x88 # define ULPI_PWR_OTG_COMP_DISABLE BIT(0) diff --git a/drivers/phy/phy-qcom-usb-hsic.c b/drivers/phy/phy-qcom-usb-hsic.c index 47690f9945b9..6dcaf04fa367 100644 --- a/drivers/phy/phy-qcom-usb-hsic.c +++ b/drivers/phy/phy-qcom-usb-hsic.c @@ -13,8 +13,6 @@ #include #include -#include "ulpi_phy.h" - #define ULPI_HSIC_CFG 0x30 #define ULPI_HSIC_IO_CAL 0x33 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 v6 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
Qualcomm SOCs have QMP phy controller that provides support to a number of controller, viz. PCIe, UFS, and USB. Add a new driver, based on generic phy framework, for this phy controller. Signed-off-by: Vivek Gautam Tested-by: Srinivas Kandagatla --- Changes since v5: - Rebased on top of phy grouping series. So the driver now sits in drivers/phy/qualcomm/ - Removed instances of readl_relaxed() and writel_relaxed(), and using readl() and writel() instead. - Replaced regulator handling with regulator_bulk() apis, so that qusb2_phy_toggle_power() method is completely dropped. - Removed memory barriers from the driver. Instead, added an extra readl() over the register in qphy_setbits() and qphy_clrbits() to ensure that the write is through to the device. - Fixed nits about return statement from probe(), phy_pipe_clk_register() and qcom_qmp_phy_create(). Changes since v4: - Added provision for child nodes representing each phy lane. Each of these nodes have their own register space for tx, rx and pcs blocks. Added provision in qcom_qmp_phy_create() to iomap these address spaces. - Added list of clocks and resets that are mandatory for each phy. qcom_qmp_phy_clk_init(), and qcom_qmp_phy_reset_init() methods request this list and maintains it with qmp. The clocks and resets are then enabled/de-asserted based on this list. This list is also updated in the binding documentation. - Removed qcom_qmp_phy_xlate() method as we don't need it with #phy-cells 0. - Removed unnecessary of_match_ptr() cast for the match table, since the driver is compiled for CONFIG_OF. - Updated copyright year to 2017. Changes since v3: - Renamed 'struct qcom_qmp_phy' to 'struct qcom_qmp' and 'struct qmp_phy_desc' to 'struct qmp_phy' to avoid any confusion in distinguishing between QMP phy block and per-lane phy which is the actual phy in Linux eyes (suggested by Bjorn Andersson). - Made error labels more idiomatic. - Modified status checking for phy pcs. - Fixed power_down_delay check. - Refactored phy_pipe_clk_register() to register the pipe clock source using devm_clk_hw_register() (suggested by Stephen). - qcom_qmp_phy_xlate() function: - Removed unnecessary 'for loop'. - Added additional check for '0' or -ve args_count. - Fixed the mixed tabs and spaces in pipe_clk_src diagram. - Removed instances of memset() since we use snprintf() for the buffers. - Refactored qphy_setbits() and qphy_clrbits() a little bit to accept base address and register offset as two separate arguments. Changes since v2: - Removed selecting 'RESET_CONTROLLER' config. - Added error handling for clk_prepare_enable paths. - Removed 'ref_clk_src' handling. Driver doesn't need to request and handle this clock. - Using readl_poll_timeout() to simplify pcs ready status polling. Also fixed the polling condition for pcs block ready status: 'Common block ready status bit is set on phy init completion, while PCS block ready status bit (PHYSTATUS) is reset on phy init completion.' - Moved out the per-lane phy creation from probe() to separate function. - Registering pipe clock source as a fixed rate clock that comes out of the PLL block of QMP phy. These source clocks serve as parent to 'pipe_clks' that are requested by pcie or usb3 phys. - Using of_device_get_match_data() to get match data. - Fixed sparse warnings for 'static' and 'const'. - Using shorter variable names in structure and in functions. - Handling various comment style shortcomings. Changes since v1: - Fixed missing mutex_unlock() calls in error cases, reported by Julia Lawall. - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled. - Added a boolean property to check if the phy has individual lane reset available. - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits. - Removed references to non-lkml links from commit message. - Moved to use separate iomem resources for each lanes. Tx, Rx and PCS offsets per lane can now come from dt bindings. drivers/phy/qualcomm/Kconfig|8 + drivers/phy/qualcomm/Makefile |1 + drivers/phy/qualcomm/phy-qcom-qmp.c | 1153 +++ 3 files changed, 1162 insertions(+) create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp.c diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig index f31f05066da8..604c7efcb221 100644 --- a/drivers/phy/qualcomm/Kconfig +++ b/drivers/phy/qualcomm/Kconfig @@ -15,6 +15,14 @@ config PHY_QCOM_IPQ806X_SATA depends on OF select GENERIC_PHY +config PHY_QCOM_QMP + tristate "Qualcomm QMP PHY Driver" + depends on OF && (ARCH_QCOM || COMPILE_TEST) + select GENERIC_PHY + help + Enable this to support the QMP PHY transceiver that is used + with controllers such as PCIe, UFS, and USB on Qualcomm chips. + config PHY_QCOM_QUSB2 tristate "Qualcomm QUSB2 PHY Driver"
Re: [PATCH] usb: gadget: dummy_hcd: Fix wrong port status macros in dummy_hub_control()
On Mon, 20 Mar 2017, Yuyang Du wrote:
> This fixes the commit: 1cd8fd2887e162ad3d06715 (usb: gadget: dummy_hcd:
> add SuperSpeed support).
>
> Signed-off-by: Yuyang Du
> ---
> drivers/usb/gadget/udc/dummy_hcd.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
> b/drivers/usb/gadget/udc/dummy_hcd.c
> index 8cabc59..56d4e95 100644
> --- a/drivers/usb/gadget/udc/dummy_hcd.c
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -2063,12 +2063,11 @@ static int dummy_hub_control(
> break;
> case USB_PORT_FEAT_POWER:
> if (hcd->speed == HCD_USB3) {
> - if (dum_hcd->port_status & USB_PORT_STAT_POWER)
> + if (dum_hcd->port_status &
> USB_SS_PORT_STAT_POWER)
> dev_dbg(dummy_dev(dum_hcd),
> "power-off\n");
> } else
> - if (dum_hcd->port_status &
> - USB_SS_PORT_STAT_POWER)
> + if (dum_hcd->port_status & USB_PORT_STAT_POWER)
> dev_dbg(dummy_dev(dum_hcd),
> "power-off\n");
> /* FALLS THROUGH */
This certainly is not a complete fix. Compare the code here with the
code for the SetPortFeature case. For one speed we need to set the
USB_PORT_STAT_POWER bit and for the other speed we need to set the
USB_SS_PORT_STAT_POWER bit in dum_hcd->port_status. 1 << wValue cannot
be the correct bit in both cases.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/4] dt-bindings: phy: Add support for QMP phy
Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.
Signed-off-by: Vivek Gautam
Acked-by: Rob Herring
---
Changes since v5:
- Added Rob's 'Ack' for the new child nodes based bindings.
- Dropped leading 0 from the address in 'reg' property.
- Fixed '@xyz' part of the node name with correct address.
Changes since v4:
- Added bindings for child nodes. Each phy lane is represented by child
node with its own register space (for tx, rx and pcs blocks), and clocks
and resets for power control facility.
- Removed register space and lane offsets for tx, rx and pcs blocks from
qmp phy node.
- #phy-cells is now part of each child node and thus must be 0.
- Added information on list of mandatory clocks and resets for each phy.
Changes since v3:
- Added #clock-cells = <1>, indicating that phy is a clock provider.
Changes since v2:
- Removed binding for "ref_clk_src" since we don't request this
clock in the driver.
- Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
- Using 'phy' for the node name.
Changes since v1:
- New patch, forked out of the original driver patch:
"phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
- Added 'Acked-by' from Rob.
- Updated bindings to include mem resource as a list of
offset - length pair for serdes block and for each lane.
- Added a new binding for 'lane-offsets' that contains offsets
to tx, rx and pcs blocks from each lane base address.
.../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 +
1 file changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
new file mode 100644
index ..e11c563a65ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,106 @@
+Qualcomm QMP PHY controller
+===
+
+QMP phy controller supports physical layer functionality for a number of
+controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+Required properties:
+ - compatible: compatible list, contains:
+ "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
+ "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+
+ - reg: offset and length of register set for PHY's common serdes block.
+
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+ interface (for pipe based PHYs). These clock are then gate-controlled
+ by gcc.
+ - #address-cells: must be 1
+ - #size-cells: must be 1
+ - ranges: must be present
+
+ - clocks: a list of phandles and clock-specifier pairs,
+ one for each entry in clock-names.
+ - clock-names: "cfg_ahb" for phy config clock,
+ "aux" for phy aux clock,
+ "ref" for 19.2 MHz ref clk,
+ For "qcom,msm8996-qmp-pcie-phy" must contain:
+ "aux", "cfg_ahb", "ref".
+ For "qcom,msm8996-qmp-usb3-phy" must contain:
+ "aux", "cfg_ahb", "ref".
+
+ - resets: a list of phandles and reset controller specifier pairs,
+ one for each entry in reset-names.
+ - reset-names: "phy" for reset of phy block,
+ "common" for phy common block reset,
+ "cfg" for phy's ahb cfg block reset (Optional).
+ For "qcom,msm8996-qmp-pcie-phy" must contain:
+"phy", "common", "cfg".
+ For "qcom,msm8996-qmp-usb3-phy" must contain
+"phy", "common".
+
+ - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+Optional properties:
+ - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
+ pll block.
+
+Required nodes:
+ - Each device node of QMP phy is required to have as many child nodes as
+ the number of lanes the PHY has.
+
+Required properties for child node:
+ - reg: list of offset and length pairs of register sets for PHY blocks -
+ tx, rx and pcs.
+
+ - #phy-cells: must be 0
+
+ - clocks: a list of phandles and clock-specifier pairs,
+ one for each entry in clock-names.
+ - clock-names: Must contain following for pcie and usb qmp phys:
+"pipe" for pipe clock specific to each lane.
+
+ - resets: a list of phandles and reset controller specifier pairs,
+ one for each entry in reset-names.
+ - reset-names: Must contain following for pcie qmp phys:
+"lane" for reset specific to each lane.
+
+Example:
+ phy@34000 {
+ compatible = "qcom,msm8996-qmp-pcie-phy";
+ reg = <0x34000 0x488>;
+ #clock-cells = <1>;
+ #address-cells = <1>;
+ #size-
[PATCH v6 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
PHY transceiver driver for QUSB2 phy controller that provides HighSpeed functionality for DWC3 controller present on Qualcomm chipsets. Signed-off-by: Vivek Gautam Reviewed-by: Stephen Boyd --- Changes since v5: - Rebased on top of phy grouping series. So the driver now sits in drivers/phy/qualcomm/ - Removed instances of readl_relaxed() and writel_relaxed(), and using readl() and writel() instead. - Replaced regulator handling with regulator_bulk() apis, so that qusb2_phy_toggle_power() method is completely dropped. - Removed memory barriers from the driver. Instead, using readl() over the register to ensure that the write is through to the device. - Fixed nits about return statement from probe() and qusb2_phy_poweron(). Changes since v4: - Updated the copyright year to 2017. - Removed unnecessary of_match_ptr() cast for the match table, since the driver is compiled for CONFIG_OF. Changes since v3: - Added 'Reviewed-by' from Stephen. - Fixed debug message for qusb2_phy_set_tune2_param(). - Replaced devm_reset_control_get() with devm_reset_control_get_by_index() since we are requesting only one reset. - Updated devm_nvmem_cell_get() with a NULL cell id. - Made error labels more idiomatic. - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept base address and register offset as two separate arguments. Changes since v2: - Removed selecting 'RESET_CONTROLLER' config. - Added error handling for clk_prepare_enable paths. - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to do that since 'xo' is modeled as parent to this clock. - Removed 'ref_clk_src' handling. Driver doesn't need to request and handle this clock. - Moved nvmem_cell_get() to probe function. - Simplified phy pll status handling. - Using of_device_get_match_data() to get match data. - Uniformly using lowercase for hex numbers. - Fixed sparse warnings. - Using shorter variable names in structure and in functions. - Handling various comment style shortcomings. Changes since v1: - removed reference to clk_enabled/pwr_enabled. - moved clock and regulator enable code to phy_power_on/off() callbacks. - fixed return on EPROBE_DEFER in qusb2_phy_probe(). - fixed phy create and phy register ordering. - removed references to non-lkml links from commit message. - took care of other minor nits. - Fixed coccinelle warnings - 'PTR_ERR applied after initialization to constant' - Addressed review comment, regarding qfprom access for tune2 param value. This driver is now based on qfprom patch[1] that allows byte access now. drivers/phy/qualcomm/Kconfig | 10 + drivers/phy/qualcomm/Makefile | 1 + drivers/phy/qualcomm/phy-qcom-qusb2.c | 491 ++ 3 files changed, 502 insertions(+) create mode 100644 drivers/phy/qualcomm/phy-qcom-qusb2.c diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig index 458d224f18a5..f31f05066da8 100644 --- a/drivers/phy/qualcomm/Kconfig +++ b/drivers/phy/qualcomm/Kconfig @@ -15,6 +15,16 @@ config PHY_QCOM_IPQ806X_SATA depends on OF select GENERIC_PHY +config PHY_QCOM_QUSB2 + tristate "Qualcomm QUSB2 PHY Driver" + depends on OF && (ARCH_QCOM || COMPILE_TEST) + select GENERIC_PHY + help + Enable this to support the HighSpeed QUSB2 PHY transceiver for USB + controllers on Qualcomm chips. This driver supports the high-speed + PHY which is usually paired with either the ChipIdea or Synopsys DWC3 + USB IPs on MSM SOCs. + config PHY_QCOM_UFS tristate "Qualcomm UFS PHY driver" depends on OF && ARCH_QCOM diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile index 07f7c7896f4d..eed5327a9206 100644 --- a/drivers/phy/qualcomm/Makefile +++ b/drivers/phy/qualcomm/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o +obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c new file mode 100644 index ..2b2b2b5222c4 --- /dev/null +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c @@ -0,0 +1,491 @@ +/* + * Copyright (c) 2017, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On 19.03.2017 23:29, Diego Viola wrote: On Fri, Mar 17, 2017 at 5:18 PM, Diego Viola wrote: On Fri, Mar 17, 2017 at 1:57 PM, Diego Viola wrote: On Fri, Mar 17, 2017 at 1:24 PM, Alan Stern wrote: On Fri, 17 Mar 2017, Diego Viola wrote: Hi, Here's the log to the netconsole dmesg capture, I've used xhci_hcd.dyndbg no_console_suspend=1 as the kernel parameters. I did the usual suspend/resume cycle with i3lock, it hung after the third attempt when trying to resume from suspend. https://bugzilla.kernel.org/attachment.cgi?id=255309 I'm not an expert on xHCI. This should be CC'ed to the xhci-hcd maintainer. Alan Stern Please let me know if I should provide something else. Thanks, Diego I've forwarded my email to Mathias Nyman. Diego Still a problem with 4.11.0-rc2-ARCH+ From a quick glance it looks like rtsx_usb_ms probaly takes a mutex (&ucr->dev_mutex) and then issues a usb_bulk_msg() and waits for it to complete with mutex held. The usb message times out, usb core kills the urb but the URB probably never gets completed, and function never returns. Everyting using ucr->dev_mutex would block, for example the kthread, rtsx_usb_detect_ms_card that continuously tries to detect a ms card, takes and releases the same ucr->dev_mutex for each try. [ 614.026502] INFO: task kworker/u8:0:5 blocked for more than 120 seconds. [ 614.027865] Not tainted 4.10.3-1-ARCH #1 [ 614.029116] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 614.030467] kworker/u8:0D0 5 2 0x [ 614.031812] Workqueue: kacpi_hotplug acpi_hotplug_work_fn [ 614.033179] Call Trace: [ 614.034550] __schedule+0x22f/0x700 [ 614.035940] schedule+0x3d/0x90 [ 614.037334] schedule_preempt_disabled+0x15/0x20 [ 614.038680] __mutex_lock_slowpath+0x19b/0x2d0 [ 614.040067] ? flush_workqueue+0x204/0x580 [ 614.041456] mutex_lock+0x23/0x30 [ 614.042163] acpi_device_hotplug+0x43/0x3e7 [ 614.042882] acpi_hotplug_work_fn+0x1e/0x29 [ 614.043612] process_one_work+0x1e5/0x470 [ 614.044356] worker_thread+0x48/0x4e0 [ 614.045077] kthread+0x101/0x140 [ 614.045788] ? process_one_work+0x470/0x470 [ 614.046495] ? kthread_create_on_node+0x60/0x60 [ 614.047215] ret_from_fork+0x2c/0x40 [ 614.047950] INFO: task rtsx_usb_ms_1:235 blocked for more than 120 seconds. [ 614.048697] Not tainted 4.10.3-1-ARCH #1 [ 614.049465] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 614.050265] rtsx_usb_ms_1 D0 235 2 0x [ 614.051064] Call Trace: [ 614.051841] __schedule+0x22f/0x700 [ 614.052626] schedule+0x3d/0x90 [ 614.053411] usb_kill_urb.part.4+0x6c/0xa0 [usbcore] [ 614.054198] ? wake_atomic_t_function+0x60/0x60 [ 614.055005] usb_kill_urb+0x21/0x30 [usbcore] [ 614.055819] usb_start_wait_urb+0xe5/0x170 [usbcore] [ 614.056652] usb_bulk_msg+0xbd/0x160 [usbcore] [ 614.057489] rtsx_usb_send_cmd+0x63/0x90 [rtsx_usb] [ 614.058306] rtsx_usb_read_register+0x6c/0xc0 [rtsx_usb] [ 614.059118] rtsx_usb_detect_ms_card+0x98/0x120 [rtsx_usb_ms] There is a lot going on in xhci during the last suspend befor this. URBs are canceled, devices reset and re-enumerated, timeout while reading descriptor, device firmware changed. It's possible we end up in a situation where xhci never givers back the URB. 4.11-rc2 has better xhci tracing, it shows each URB enqueue and dequeue and giveback. Could you try enabling xhci tracing before suspending (not the same as xhci verbose dynamic debug) It will generate a lot of data, so better to remove all extra USB devices. xhci tracing can be added with: mount -t debugfs none /sys/kernel/debug echo xhci-hcd >> /sys/kernel/debug/tracing/set_event and then send the output of cat /sys/kernel/debug/tracing/trace -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 RFC 3/7] net: lan78xx: update for phy_(read|write)_mmd_indirect() removal
> lan78xx appears to use phylib in a rather weird way, accessing the PHY
> partly through phylib, and partly by makign direct accesses to it,
> including to the Clause 45 registers. As the indirect MMD accessors are
> going away, update this driver to use the plain phy_(read|write)_mmd()
> accessors instead.
>
> Signed-off-by: Russell King
Acked-by: Woojung Huh
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
extcon-usb-gpio ACPI support
There is a so called ACPI support for extcon-usb-gpio. Since GPIO ACPI library is going to be stricter and this driver might not work anymore. I would like to know: 1. Is there any real DSDT which contains device enumerated by this driver? 2. If "yes" on 1, does that DSDT contain _DSD method for the device? 3. If "no" on 2, how is it supposed to work at all? So, regarding on the answers, I am in between of reverting commit 942c7924a51edb75baf805679141e97140e07218 Author: Lu Baolu Date: Tue Apr 26 08:35:54 2016 +0900 extcon: usb-gpio: add support for ACPI gpio interface *or* someone better to add real DSDT example to Documentation regarding this driver. -- Andy Shevchenko Intel Finland Oy -- 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 v6 1/4] dt-bindings: phy: Add support for QUSB2 phy
Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.
Signed-off-by: Vivek Gautam
Acked-by: Rob Herring
---
Changes since v5:
- Removed leading 0 from the address in 'reg' property.
Changes since v4:
- None.
Changes since v3:
- Added 'Acked-by' from Rob.
- Removed 'reset-names' and 'nvmem-cell-names' from the bindings
since we use only one cell.
Changes since v2:
- Removed binding for "ref_clk_src" since we don't request this
clock in the driver.
- Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
- Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
- Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
'efuse' suffix to nvmem cell.
- Addressed s/qusb2phy/phy for the node name.
Changes since v1:
- New patch, forked out of the original driver patch:
"phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
- Updated dt bindings to remove 'hstx-trim-bit-offset' and
'hstx-trim-bit-len' bindings.
.../devicetree/bindings/phy/qcom-qusb2-phy.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..a6d19acde9e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,45 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - clocks: a list of phandles and clock-specifier pairs,
+ one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+ "ref" for 19.2 MHz ref clk,
+ "iface" for phy interface clock (Optional).
+
+ - vdd-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+ tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+ hsusb_phy: phy@7411000 {
+ compatible = "qcom,msm8996-qusb2-phy";
+ reg = <0x7411000 0x180>;
+ #phy-cells = <0>;
+
+ clocks = <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+ <&gcc GCC_RX1_USB2_CLKREF_CLK>,
+ clock-names = "cfg_ahb", "ref";
+
+ vdd-phy-supply = <&pm8994_s2>;
+ vdda-pll-supply = <&pm8994_l12>;
+ vdda-phy-dpdm-supply = <&pm8994_l24>;
+
+ resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+ nvmem-cells = <&qusb2p_hstx_trim>;
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v6 0/4] phy: USB and PCIe phy drivers for Qcom chipsets
This patch series adds couple of PHY drivers for Qualcomm chipsets. a) qcom-qusb2 phy driver: that provides High Speed USB functionality. b) qcom-qmp phy driver: that is a combo phy providing support for USB3, PCIe, UFS and few other controllers. The patches are based on next branch of linux-phy tree, and depends on phy driver grouping series[1]: [PATCH v4 0/3] phy: Group phy drivers based on vendor listing. These patches have been tested on Dragon board db820c hardware with required set of dt patches and the patches to get rpm up on msm8996. Couple of other patches [2, 3] fixing DMA config for XHCI are also pulled in for testing. The complete branch is available in github [4]. Changes since v5: - Addressed review comments from Bjorn: - Removed instances of readl/wirtel_relaxed calls from the drivers. Instead, using simple readl/writel. Inserting a readl after a writel to ensure the write is through to the device. - Replaced regulator handling with regulator_bulk_** apis. This helps in cutting down a lot of regulator handling code. - Fixed minor return statements. Changes since v4: - Addressed comment to add child nodes for qmp phy driver. Each phy lane now has a separate child node under the main qmp node. - Modified the clock and reset initialization and enable methods. Different phys - pcie, usb and later ufs, have varying number of clocks and resets that are mandatory. So adding provision for clocks and reset lists helps in requesting all mandatory resources for individual phys and handle their failure cases accordingly. Changes since v3: - Addressed review comments given by Rob and Stephen for qusb2 phy and qmp phy bindings respectively. - Addressed review comments given by Stephen and Bjorn for qmp phy driver. Changes since v2: - Addressed review comments given by Rob and Stephen for bindings. - Addressed the review comments given by Stephen for the qusb2 and qmp phy drivers. Changes since v1: - Moved device tree binding documentation to separate patches, as suggested by Rob. - Addressed review comment regarding qfprom accesses by qusb2 phy driver, given by Rob. - Addressed review comments from Kishon. - Addressed review comments from Srinivas for QMP phy driver. - Addressed kbuild warning. Please see individual patches for detailed changelogs. [1] https://www.spinics.net/lists/arm-kernel/msg569990.html [2] https://patchwork.kernel.org/patch/9567767/ [3] https://patchwork.kernel.org/patch/9567779/ [4] https://github.com/vivekgautam1/linux/tree/linux-phy-next-qcom-phy-db820c Vivek Gautam (4): dt-bindings: phy: Add support for QUSB2 phy phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips dt-bindings: phy: Add support for QMP phy phy: qcom-qmp: new qmp phy driver for qcom-chipsets .../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 ++ .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 45 + drivers/phy/qualcomm/Kconfig | 18 + drivers/phy/qualcomm/Makefile |2 + drivers/phy/qualcomm/phy-qcom-qmp.c| 1153 drivers/phy/qualcomm/phy-qcom-qusb2.c | 491 + 6 files changed, 1815 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp.c create mode 100644 drivers/phy/qualcomm/phy-qcom-qusb2.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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/4] cdc-acm: fix possible invalid access when processing notification
Am Samstag, den 18.03.2017, 19:52 +0100 schrieb Tobias Herzog: > Notifications may only be 8 bytes so long. Accessing the 9th and > 10th byte of unimplemented/unknown notifications may be insecure. > Also check the length of known notifications before accessing anything > behind the 8th byte. > This is fixing a potential security issue. Please make it first in the series and CC it to sta...@vger.kernel.org Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] cdc-acm: reassemble fragmented notifications
Am Samstag, den 18.03.2017, 19:52 +0100 schrieb Tobias Herzog:
> USB devices may have very limitited endpoint packet sizes, so that
> notifications can not be transferred within one single usb packet.
> Reassembling of multiple packages may be necessary.
Hi,
almost perfect.
A few new issue. Comments inline.
>
> + struct usb_cdc_notification *dr = (struct usb_cdc_notification *)buf;
> + unsigned char *data = (unsigned char *)(dr + 1);
This is border line incorrect. It depends on the compiler not
adding padding. Please make it
buf + sizeof(struct usb_cdc_notification)
> - usb_mark_last_busy(acm->dev);
> -
> - data = (unsigned char *)(dr + 1);
> switch (dr->bNotificationType) {
> case USB_CDC_NOTIFY_NETWORK_CONNECTION:
> dev_dbg(&acm->control->dev,
> @@ -363,8 +337,77 @@ static void acm_ctrl_irq(struct urb *urb)
> __func__,
> dr->bNotificationType, dr->wIndex,
> dr->wLength, data[0], data[1]);
> + }
> +}
> +
> +/* control interface reports status changes with "interrupt" transfers */
> +static void acm_ctrl_irq(struct urb *urb)
> +{
> + struct acm *acm = urb->context;
> + struct usb_cdc_notification *dr = urb->transfer_buffer;
> + unsigned int current_size = urb->actual_length;
> + unsigned int expected_size, copy_size;
> + int retval;
> + int status = urb->status;
> +
> + switch (status) {
> + case 0:
> + /* success */
> break;
> + case -ECONNRESET:
> + case -ENOENT:
> + case -ESHUTDOWN:
> + /* this urb is terminated, clean up */
> + acm->nb_index = 0;
> + dev_dbg(&acm->control->dev,
> + "%s - urb shutting down with status: %d\n",
> + __func__, status);
> + return;
> + default:
> + dev_dbg(&acm->control->dev,
> + "%s - nonzero urb status received: %d\n",
> + __func__, status);
> + goto exit;
> }
> +
> + usb_mark_last_busy(acm->dev);
> +
> + if (acm->nb_index)
> + dr = (struct usb_cdc_notification *)acm->notification_buffer;
> +
> + /* size = notification-header + (optional) data */
> + expected_size = sizeof(struct usb_cdc_notification) +
> + le16_to_cpu(dr->wLength);
> +
> + if (current_size < expected_size) {
> + /* notification is transmitted fragmented, reassemble */
> + if (acm->nb_size < expected_size) {
> + if (acm->nb_size) {
> + kfree(acm->notification_buffer);
> + acm->nb_size = 0;
> + }
> + acm->notification_buffer =
> + kmalloc(expected_size, GFP_ATOMIC);
Given how kmalloc works you'd better round this up to a power of two.
> + if (!acm->notification_buffer)
> + goto exit;
This is most subtle. Please add a comment that this prevents a double
free if we get a disconnect()
> + acm->nb_size = expected_size;
> + }
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Mon, Mar 20, 2017 at 11:21 AM, Mathias Nyman wrote: > On 19.03.2017 23:29, Diego Viola wrote: >> >> On Fri, Mar 17, 2017 at 5:18 PM, Diego Viola >> wrote: >>> >>> On Fri, Mar 17, 2017 at 1:57 PM, Diego Viola >>> wrote: On Fri, Mar 17, 2017 at 1:24 PM, Alan Stern wrote: > > On Fri, 17 Mar 2017, Diego Viola wrote: > >> Hi, >> >> Here's the log to the netconsole dmesg capture, I've used >> xhci_hcd.dyndbg no_console_suspend=1 as the kernel parameters. >> >> I did the usual suspend/resume cycle with i3lock, it hung after the >> third attempt when trying to resume from suspend. >> >> https://bugzilla.kernel.org/attachment.cgi?id=255309 > > > I'm not an expert on xHCI. This should be CC'ed to the xhci-hcd > maintainer. > > Alan Stern > >> >> Please let me know if I should provide something else. >> >> Thanks, >> Diego >> > I've forwarded my email to Mathias Nyman. Diego >>> >>> >>> Still a problem with 4.11.0-rc2-ARCH+ >>> > > From a quick glance it looks like rtsx_usb_ms probaly takes a mutex > (&ucr->dev_mutex) > and then issues a usb_bulk_msg() and waits for it to complete with mutex > held. > The usb message times out, usb core kills the urb but the URB probably never > gets completed, > and function never returns. > > Everyting using ucr->dev_mutex would block, for example the kthread, > rtsx_usb_detect_ms_card > that continuously tries to detect a ms card, takes and releases the same > ucr->dev_mutex for > each try. > > [ 614.026502] INFO: task kworker/u8:0:5 blocked for more than 120 seconds. > [ 614.027865] Not tainted 4.10.3-1-ARCH #1 > [ 614.029116] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 614.030467] kworker/u8:0D0 5 2 0x > [ 614.031812] Workqueue: kacpi_hotplug acpi_hotplug_work_fn > [ 614.033179] Call Trace: > [ 614.034550] __schedule+0x22f/0x700 > [ 614.035940] schedule+0x3d/0x90 > [ 614.037334] schedule_preempt_disabled+0x15/0x20 > [ 614.038680] __mutex_lock_slowpath+0x19b/0x2d0 > [ 614.040067] ? flush_workqueue+0x204/0x580 > [ 614.041456] mutex_lock+0x23/0x30 > [ 614.042163] acpi_device_hotplug+0x43/0x3e7 > [ 614.042882] acpi_hotplug_work_fn+0x1e/0x29 > [ 614.043612] process_one_work+0x1e5/0x470 > [ 614.044356] worker_thread+0x48/0x4e0 > [ 614.045077] kthread+0x101/0x140 > [ 614.045788] ? process_one_work+0x470/0x470 > [ 614.046495] ? kthread_create_on_node+0x60/0x60 > [ 614.047215] ret_from_fork+0x2c/0x40 > [ 614.047950] INFO: task rtsx_usb_ms_1:235 blocked for more than 120 > seconds. > [ 614.048697] Not tainted 4.10.3-1-ARCH #1 > [ 614.049465] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 614.050265] rtsx_usb_ms_1 D0 235 2 0x > [ 614.051064] Call Trace: > [ 614.051841] __schedule+0x22f/0x700 > [ 614.052626] schedule+0x3d/0x90 > [ 614.053411] usb_kill_urb.part.4+0x6c/0xa0 [usbcore] > [ 614.054198] ? wake_atomic_t_function+0x60/0x60 > [ 614.055005] usb_kill_urb+0x21/0x30 [usbcore] > [ 614.055819] usb_start_wait_urb+0xe5/0x170 [usbcore] > [ 614.056652] usb_bulk_msg+0xbd/0x160 [usbcore] > [ 614.057489] rtsx_usb_send_cmd+0x63/0x90 [rtsx_usb] > [ 614.058306] rtsx_usb_read_register+0x6c/0xc0 [rtsx_usb] > [ 614.059118] rtsx_usb_detect_ms_card+0x98/0x120 [rtsx_usb_ms] > > There is a lot going on in xhci during the last suspend befor this. > URBs are canceled, devices reset and re-enumerated, timeout while reading > descriptor, > device firmware changed. > > It's possible we end up in a situation where xhci never givers back the > URB. > > 4.11-rc2 has better xhci tracing, it shows each URB enqueue and dequeue and > giveback. > > Could you try enabling xhci tracing before suspending (not the same as xhci > verbose dynamic debug) > It will generate a lot of data, so better to remove all extra USB devices. > > xhci tracing can be added with: > > mount -t debugfs none /sys/kernel/debug > echo xhci-hcd >> /sys/kernel/debug/tracing/set_event > > and then send the output of cat /sys/kernel/debug/tracing/trace > > -Mathias > > https://bugzilla.kernel.org/attachment.cgi?id=255367 This is with Linux 4.11.0-rc3-ARCH. USB mouse/keyboard was unplugged before booting the machine. I didn't do a suspend/resume before getting this trace, should I do that? Should I reproduce the hang and get a netconsole dmesg capture with tracing enabled? Thanks, Diego -- 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: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On 20.03.2017 17:39, Diego Viola wrote: On Mon, Mar 20, 2017 at 11:21 AM, Mathias Nyman wrote: On 19.03.2017 23:29, Diego Viola wrote: Still a problem with 4.11.0-rc2-ARCH+ 4.11-rc2 has better xhci tracing, it shows each URB enqueue and dequeue and giveback. Could you try enabling xhci tracing before suspending (not the same as xhci verbose dynamic debug) It will generate a lot of data, so better to remove all extra USB devices. xhci tracing can be added with: mount -t debugfs none /sys/kernel/debug echo xhci-hcd >> /sys/kernel/debug/tracing/set_event and then send the output of cat /sys/kernel/debug/tracing/trace https://bugzilla.kernel.org/attachment.cgi?id=255367 This is with Linux 4.11.0-rc3-ARCH. USB mouse/keyboard was unplugged before booting the machine. I didn't do a suspend/resume before getting this trace, should I do that? Should I reproduce the hang and get a netconsole dmesg capture with tracing enabled? A trace and a dmesg of the same suspend/reusume hang would be great. And if you can then one of a succesful suspend/resume for reference. (I haven't yet checked the one you added to bugzilla) -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
[PATCH v2] usb: hub: Do not attempt to autosuspend disconnected devices
While running a bind/unbind stress test with the dwc3 usb driver on rk3399, the following crash was observed. Unable to handle kernel NULL pointer dereference at virtual address 0218 pgd = ffc00165f000 [0218] *pgd=0174f003, *pud=0174f003, *pmd=01750003, *pte=00e801751713 Internal error: Oops: 9605 [#1] PREEMPT SMP Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507 Hardware name: Google Kevin (DT) Workqueue: pm pm_runtime_work task: ffc0ac54 ti: ffc0af4d4000 task.ti: ffc0af4d4000 PC is at autosuspend_check+0x74/0x174 LR is at autosuspend_check+0x70/0x174 ... Call trace: [] autosuspend_check+0x74/0x174 [] usb_runtime_idle+0x20/0x40 [] __rpm_callback+0x48/0x7c [] rpm_idle+0x1e8/0x498 [] pm_runtime_work+0x88/0xcc [] process_one_work+0x390/0x6b8 [] worker_thread+0x480/0x610 [] kthread+0x164/0x178 [] ret_from_fork+0x10/0x40 Source: (gdb) l *0xffc00080dcc0 0xffc00080dcc0 is in autosuspend_check (drivers/usb/core/driver.c:1778). 1773/* We don't need to check interfaces that are 1774 * disabled for runtime PM. Either they are unbound 1775 * or else their drivers don't support autosuspend 1776 * and so they are permanently active. 1777 */ 1778if (intf->dev.power.disable_depth) 1779continue; 1780if (atomic_read(&intf->dev.power.usage_count) > 0) 1781return -EBUSY; 1782w |= intf->needs_remote_wakeup; Code analysis shows that intf is set to NULL in usb_disable_device() prior to setting actconfig to NULL. At the same time, usb_runtime_idle() does not lock the usb device, and neither does any of the functions in the traceback. This means that there is no protection against a race condition where usb_disable_device() is removing dev->actconfig->interface[] pointers while those are being accessed from autosuspend_check(). To solve the problem, synchronize and validate device state between autosuspend_check() and usb_disconnect(). Signed-off-by: Guenter Roeck --- v2: Do not disable autosuspend in usb_disconnect(). Instead, check the usb device state in autosuspend_check(). In usb_disconnect(), call pm_runtime_barrier() earlier, immediately after changing the USB device state. drivers/usb/core/driver.c | 3 +++ drivers/usb/core/hub.c| 7 +++ 2 files changed, 10 insertions(+) diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c index 7ebdf2a4e8fe..eb87a259d55c 100644 --- a/drivers/usb/core/driver.c +++ b/drivers/usb/core/driver.c @@ -1781,6 +1781,9 @@ static int autosuspend_check(struct usb_device *udev) int w, i; struct usb_interface*intf; + if (udev->state == USB_STATE_NOTATTACHED) + return -ENODEV; + /* Fail if autosuspend is disabled, or any interfaces are in use, or * any interface drivers require remote wakeup but it isn't available. */ diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 57bb427c8878..fd80513aaeff 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -2084,6 +2084,13 @@ void usb_disconnect(struct usb_device **pdev) * this quiesces everything except pending urbs. */ usb_set_device_state(udev, USB_STATE_NOTATTACHED); + + /* +* Ensure that the pm runtime code knows that the USB device +* is in the process of being disconnected. +*/ + pm_runtime_barrier(&udev->dev); + dev_info(&udev->dev, "USB disconnect, device number %d\n", udev->devnum); -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb: hub: Fix error loop seen after hub communication errors
Hi, On Thu, Mar 16, 2017 at 12:24 PM, Guenter Roeck wrote: > @@ -1198,7 +1201,7 @@ static void hub_activate(struct usb_hub *hub, enum > hub_activation_type type) > > /* Scan all ports that need attention */ > kick_hub_wq(hub); > - > +abort: One tiny nit that could be done when applying this patch is to add a space before "abort". Other goto labels in this function are preceded by a space and it's sane to try to match the existing coding convention in the function rather than trying to mix and match. Other than that this patch seems sane to me, but I am by no means an expert on this code. ;) -Doug -- 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 v4] usb: hub: Fix error loop seen after hub communication errors
While stress testing a usb controller using a bind/unbind looop, the
following error loop was observed.
usb 7-1.2: new low-speed USB device number 3 using xhci-hcd
usb 7-1.2: hub failed to enable device, error -108
usb 7-1-port2: cannot disable (err = -22)
usb 7-1-port2: couldn't allocate usb_device
usb 7-1-port2: cannot disable (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22
** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err =
-22)
This continues forever. After adding tracebacks into the code,
the call sequence leading to this is found to be as follows.
[] hub_activate+0x368/0x7b8
[] hub_resume+0x2c/0x3c
[] usb_resume_interface.isra.6+0x128/0x158
[] usb_suspend_both+0x1e8/0x288
[] usb_runtime_suspend+0x3c/0x98
[] __rpm_callback+0x48/0x7c
[] rpm_callback+0xa8/0xd4
[] rpm_suspend+0x84/0x758
[] rpm_idle+0x2c8/0x498
[] __pm_runtime_idle+0x60/0xac
[] usb_autopm_put_interface+0x6c/0x7c
[] hub_event+0x10ac/0x12ac
[] process_one_work+0x390/0x6b8
[] worker_thread+0x480/0x610
[] kthread+0x164/0x178
[] ret_from_fork+0x10/0x40
kick_hub_wq() is called from hub_activate() even after failures to
communicate with the hub. This results in an endless sequence of
hub event -> hub activate -> wq trigger -> hub event -> ...
Provide two solutions for the problem.
- Only trigger the hub event queue if communication with the hub
is successful.
- After a suspend failure, only resume already suspended interfaces
if the communication with the device is still possible.
Each of the changes fixes the observed problem. Use both to improve
robustness.
Acked-by: Alan Stern
Signed-off-by: Guenter Roeck
---
v4: Other code uses a space before labels in hub_activate(). Do the same
for consistency.
v3: In hub.c, abort immediately if hub_port_status() returns an error.
Since hub_port_status() already logs the error, don't log it again.
In device,c, log the error return value from usb_suspend_device()
if usb_get_status() failed as well.
Don't check if the hub is still accessible if the error returned
from hub_port_status() is -EBUSY.
v2: Instead of not triggering the hub wq after an error to submit an urb,
implement a more complex error detection and handling. Do it in two
places. Marked as RFC to determine if one (or both) of those solutions
are viable.
drivers/usb/core/driver.c | 18 ++
drivers/usb/core/hub.c| 5 -
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index cdee5130638b..7ebdf2a4e8fe 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1331,6 +1331,24 @@ static int usb_suspend_both(struct usb_device *udev,
pm_message_t msg)
*/
if (udev->parent && !PMSG_IS_AUTO(msg))
status = 0;
+
+ /*
+* If the device is inaccessible, don't try to resume
+* suspended interfaces and just return the error.
+*/
+ if (status && status != -EBUSY) {
+ int err;
+ u16 devstat;
+
+ err = usb_get_status(udev, USB_RECIP_DEVICE, 0,
+&devstat);
+ if (err) {
+ dev_err(&udev->dev,
+ "Failed to suspend device, error %d\n",
+ status);
+ goto done;
+ }
+ }
}
/* If the suspend failed, resume interfaces that did get suspended */
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5286bf67869a..2e047f982af3 100644
--- a/drivers/usb/cor
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Mon, Mar 20, 2017 at 1:32 PM, Mathias Nyman wrote: > On 20.03.2017 17:39, Diego Viola wrote: >> >> On Mon, Mar 20, 2017 at 11:21 AM, Mathias Nyman >> wrote: >>> >>> On 19.03.2017 23:29, Diego Viola wrote: > > Still a problem with 4.11.0-rc2-ARCH+ >>> >>> 4.11-rc2 has better xhci tracing, it shows each URB enqueue and dequeue >>> and >>> giveback. >>> >>> Could you try enabling xhci tracing before suspending (not the same as >>> xhci >>> verbose dynamic debug) >>> It will generate a lot of data, so better to remove all extra USB >>> devices. >>> >>> xhci tracing can be added with: >>> >>> mount -t debugfs none /sys/kernel/debug >>> echo xhci-hcd >> /sys/kernel/debug/tracing/set_event >>> >>> and then send the output of cat /sys/kernel/debug/tracing/trace >> >> >> https://bugzilla.kernel.org/attachment.cgi?id=255367 >> >> This is with Linux 4.11.0-rc3-ARCH. >> >> USB mouse/keyboard was unplugged before booting the machine. >> >> I didn't do a suspend/resume before getting this trace, should I do that? >> >> Should I reproduce the hang and get a netconsole dmesg capture with >> tracing enabled? > > > A trace and a dmesg of the same suspend/reusume hang would be great. I can capture the dmesg with netconsole once the machine hangs, but I'm not sure how I could capture /sys/kernel/debug/tracing/trace after the hang. I'm unable to use ssh after the hang. > And if you can then one of a succesful suspend/resume for reference. Here's the trace after a successful suspend/resume: https://bugzilla.kernel.org/attachment.cgi?id=255369 > > (I haven't yet checked the one you added to bugzilla) > > -Mathias Diego -- 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: hub: Do not attempt to autosuspend disconnected devices
On Mon, 20 Mar 2017, Guenter Roeck wrote: > While running a bind/unbind stress test with the dwc3 usb driver on rk3399, > the following crash was observed. > > Unable to handle kernel NULL pointer dereference at virtual address 0218 > pgd = ffc00165f000 > [0218] *pgd=0174f003, *pud=0174f003, > *pmd=01750003, *pte=00e801751713 ... > Code analysis shows that intf is set to NULL in usb_disable_device() prior > to setting actconfig to NULL. At the same time, usb_runtime_idle() does not > lock the usb device, and neither does any of the functions in the > traceback. This means that there is no protection against a race condition > where usb_disable_device() is removing dev->actconfig->interface[] pointers > while those are being accessed from autosuspend_check(). > > To solve the problem, synchronize and validate device state between > autosuspend_check() and usb_disconnect(). > > Signed-off-by: Guenter Roeck > --- > v2: Do not disable autosuspend in usb_disconnect(). Instead, check the > usb device state in autosuspend_check(). > In usb_disconnect(), call pm_runtime_barrier() earlier, immediately > after changing the USB device state. > > drivers/usb/core/driver.c | 3 +++ > drivers/usb/core/hub.c| 7 +++ > 2 files changed, 10 insertions(+) > > diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c > index 7ebdf2a4e8fe..eb87a259d55c 100644 > --- a/drivers/usb/core/driver.c > +++ b/drivers/usb/core/driver.c > @@ -1781,6 +1781,9 @@ static int autosuspend_check(struct usb_device *udev) > int w, i; > struct usb_interface*intf; > > + if (udev->state == USB_STATE_NOTATTACHED) > + return -ENODEV; > + > /* Fail if autosuspend is disabled, or any interfaces are in use, or >* any interface drivers require remote wakeup but it isn't available. >*/ > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index 57bb427c8878..fd80513aaeff 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -2084,6 +2084,13 @@ void usb_disconnect(struct usb_device **pdev) >* this quiesces everything except pending urbs. >*/ > usb_set_device_state(udev, USB_STATE_NOTATTACHED); > + > + /* > + * Ensure that the pm runtime code knows that the USB device > + * is in the process of being disconnected. > + */ > + pm_runtime_barrier(&udev->dev); > + > dev_info(&udev->dev, "USB disconnect, device number %d\n", > udev->devnum); > Very minor nit: I would place the pm_runtime_barrier() after the dev_info(), so that we would know the device is going away if anything should go wrong during the barrier call. Aside from that, Acked-by: Alan Stern 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] usb: hub: Do not attempt to autosuspend disconnected devices
On Mon, Mar 20, 2017 at 05:12:20PM -0400, Alan Stern wrote: > On Mon, 20 Mar 2017, Guenter Roeck wrote: > > > While running a bind/unbind stress test with the dwc3 usb driver on rk3399, > > the following crash was observed. > > > > Unable to handle kernel NULL pointer dereference at virtual address 0218 > > pgd = ffc00165f000 > > [0218] *pgd=0174f003, *pud=0174f003, > > *pmd=01750003, *pte=00e801751713 > > ... > > > Code analysis shows that intf is set to NULL in usb_disable_device() prior > > to setting actconfig to NULL. At the same time, usb_runtime_idle() does not > > lock the usb device, and neither does any of the functions in the > > traceback. This means that there is no protection against a race condition > > where usb_disable_device() is removing dev->actconfig->interface[] pointers > > while those are being accessed from autosuspend_check(). > > > > To solve the problem, synchronize and validate device state between > > autosuspend_check() and usb_disconnect(). > > > > Signed-off-by: Guenter Roeck > > --- > > v2: Do not disable autosuspend in usb_disconnect(). Instead, check the > > usb device state in autosuspend_check(). > > In usb_disconnect(), call pm_runtime_barrier() earlier, immediately > > after changing the USB device state. > > > > drivers/usb/core/driver.c | 3 +++ > > drivers/usb/core/hub.c| 7 +++ > > 2 files changed, 10 insertions(+) > > > > diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c > > index 7ebdf2a4e8fe..eb87a259d55c 100644 > > --- a/drivers/usb/core/driver.c > > +++ b/drivers/usb/core/driver.c > > @@ -1781,6 +1781,9 @@ static int autosuspend_check(struct usb_device *udev) > > int w, i; > > struct usb_interface*intf; > > > > + if (udev->state == USB_STATE_NOTATTACHED) > > + return -ENODEV; > > + > > /* Fail if autosuspend is disabled, or any interfaces are in use, or > > * any interface drivers require remote wakeup but it isn't available. > > */ > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > index 57bb427c8878..fd80513aaeff 100644 > > --- a/drivers/usb/core/hub.c > > +++ b/drivers/usb/core/hub.c > > @@ -2084,6 +2084,13 @@ void usb_disconnect(struct usb_device **pdev) > > * this quiesces everything except pending urbs. > > */ > > usb_set_device_state(udev, USB_STATE_NOTATTACHED); > > + > > + /* > > +* Ensure that the pm runtime code knows that the USB device > > +* is in the process of being disconnected. > > +*/ > > + pm_runtime_barrier(&udev->dev); > > + > > dev_info(&udev->dev, "USB disconnect, device number %d\n", > > udev->devnum); > > > > Very minor nit: I would place the pm_runtime_barrier() after the > dev_info(), so that we would know the device is going away if anything > should go wrong during the barrier call. > Makes sense. I'll change that and resend. Thanks, Guenter > Aside from that, > > Acked-by: Alan Stern > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] usb: hub: Do not attempt to autosuspend disconnected devices
While running a bind/unbind stress test with the dwc3 usb driver on rk3399, the following crash was observed. Unable to handle kernel NULL pointer dereference at virtual address 0218 pgd = ffc00165f000 [0218] *pgd=0174f003, *pud=0174f003, *pmd=01750003, *pte=00e801751713 Internal error: Oops: 9605 [#1] PREEMPT SMP Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507 Hardware name: Google Kevin (DT) Workqueue: pm pm_runtime_work task: ffc0ac54 ti: ffc0af4d4000 task.ti: ffc0af4d4000 PC is at autosuspend_check+0x74/0x174 LR is at autosuspend_check+0x70/0x174 ... Call trace: [] autosuspend_check+0x74/0x174 [] usb_runtime_idle+0x20/0x40 [] __rpm_callback+0x48/0x7c [] rpm_idle+0x1e8/0x498 [] pm_runtime_work+0x88/0xcc [] process_one_work+0x390/0x6b8 [] worker_thread+0x480/0x610 [] kthread+0x164/0x178 [] ret_from_fork+0x10/0x40 Source: (gdb) l *0xffc00080dcc0 0xffc00080dcc0 is in autosuspend_check (drivers/usb/core/driver.c:1778). 1773/* We don't need to check interfaces that are 1774 * disabled for runtime PM. Either they are unbound 1775 * or else their drivers don't support autosuspend 1776 * and so they are permanently active. 1777 */ 1778if (intf->dev.power.disable_depth) 1779continue; 1780if (atomic_read(&intf->dev.power.usage_count) > 0) 1781return -EBUSY; 1782w |= intf->needs_remote_wakeup; Code analysis shows that intf is set to NULL in usb_disable_device() prior to setting actconfig to NULL. At the same time, usb_runtime_idle() does not lock the usb device, and neither does any of the functions in the traceback. This means that there is no protection against a race condition where usb_disable_device() is removing dev->actconfig->interface[] pointers while those are being accessed from autosuspend_check(). To solve the problem, synchronize and validate device state between autosuspend_check() and usb_disconnect(). Acked-by: Alan Stern Signed-off-by: Guenter Roeck --- v3: Call pm_runtime_barrier() after dev_info() v2: Do not disable autosuspend in usb_disconnect(). Instead, check the usb device state in autosuspend_check(). In usb_disconnect(), call pm_runtime_barrier() earlier, immediately after changing the USB device state. drivers/usb/core/driver.c | 3 +++ drivers/usb/core/hub.c| 6 ++ 2 files changed, 9 insertions(+) diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c index 7ebdf2a4e8fe..eb87a259d55c 100644 --- a/drivers/usb/core/driver.c +++ b/drivers/usb/core/driver.c @@ -1781,6 +1781,9 @@ static int autosuspend_check(struct usb_device *udev) int w, i; struct usb_interface*intf; + if (udev->state == USB_STATE_NOTATTACHED) + return -ENODEV; + /* Fail if autosuspend is disabled, or any interfaces are in use, or * any interface drivers require remote wakeup but it isn't available. */ diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 2e047f982af3..9dca59ef18b3 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -2087,6 +2087,12 @@ void usb_disconnect(struct usb_device **pdev) dev_info(&udev->dev, "USB disconnect, device number %d\n", udev->devnum); + /* +* Ensure that the pm runtime code knows that the USB device +* is in the process of being disconnected. +*/ + pm_runtime_barrier(&udev->dev); + usb_lock_device(udev); hub_disconnect_children(udev); -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Mon, Mar 20, 2017 at 3:27 PM, Diego Viola wrote: > On Mon, Mar 20, 2017 at 1:32 PM, Mathias Nyman > wrote: >> On 20.03.2017 17:39, Diego Viola wrote: >>> >>> On Mon, Mar 20, 2017 at 11:21 AM, Mathias Nyman >>> wrote: On 19.03.2017 23:29, Diego Viola wrote: > > >> >> Still a problem with 4.11.0-rc2-ARCH+ 4.11-rc2 has better xhci tracing, it shows each URB enqueue and dequeue and giveback. Could you try enabling xhci tracing before suspending (not the same as xhci verbose dynamic debug) It will generate a lot of data, so better to remove all extra USB devices. xhci tracing can be added with: mount -t debugfs none /sys/kernel/debug echo xhci-hcd >> /sys/kernel/debug/tracing/set_event and then send the output of cat /sys/kernel/debug/tracing/trace >>> >>> >>> https://bugzilla.kernel.org/attachment.cgi?id=255367 >>> >>> This is with Linux 4.11.0-rc3-ARCH. >>> >>> USB mouse/keyboard was unplugged before booting the machine. >>> >>> I didn't do a suspend/resume before getting this trace, should I do that? >>> >>> Should I reproduce the hang and get a netconsole dmesg capture with >>> tracing enabled? >> >> >> A trace and a dmesg of the same suspend/reusume hang would be great. > > I can capture the dmesg with netconsole once the machine hangs, but > I'm not sure how I could capture /sys/kernel/debug/tracing/trace after > the hang. I'm unable to use ssh after the hang. > >> And if you can then one of a succesful suspend/resume for reference. > > Here's the trace after a successful suspend/resume: > > https://bugzilla.kernel.org/attachment.cgi?id=255369 > >> >> (I haven't yet checked the one you added to bugzilla) >> >> -Mathias > > Diego ftrace_dump_on_oops is what I was looking for. Diego -- 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 v4 1/8] phy: phy-mt65xx-usb3: improve RX detection stable time
Hi Kishon, Do you have any comments or suggestions on the series of patches? Thanks a lot On Sat, 2017-03-11 at 14:22 +0800, Chunfeng Yun wrote: > The default value of RX detection stable time is 10us, and this > margin is too big for some critical cases which cause U3 link fail > and link to U2(probability is about 1%). So change it to 5us. > > Signed-off-by: Chunfeng Yun > --- > drivers/phy/phy-mt65xx-usb3.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c > index d972067..fe2392a 100644 > --- a/drivers/phy/phy-mt65xx-usb3.c > +++ b/drivers/phy/phy-mt65xx-usb3.c > @@ -112,6 +112,14 @@ > #define P3D_RG_CDR_BIR_LTD0 GENMASK(12, 8) > #define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8) > > +#define U3P_U3_PHYD_RXDET1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x128) > +#define P3D_RG_RXDET_STB2_SETGENMASK(17, 9) > +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9) > + > +#define U3P_U3_PHYD_RXDET2 (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c) > +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0) > +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x) (0x1ff & (x)) > + > #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018) > #define XC3_RG_U3_XTAL_RX_PWDBIT(9) > #define XC3_RG_U3_FRC_XTAL_RX_PWDBIT(8) > @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy, > tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3); > writel(tmp, port_base + U3P_PHYD_CDR1); > > + tmp = readl(port_base + U3P_U3_PHYD_RXDET1); > + tmp &= ~P3D_RG_RXDET_STB2_SET; > + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10); > + writel(tmp, port_base + U3P_U3_PHYD_RXDET1); > + > + tmp = readl(port_base + U3P_U3_PHYD_RXDET2); > + tmp &= ~P3D_RG_RXDET_STB2_SET_P3; > + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10); > + writel(tmp, port_base + U3P_U3_PHYD_RXDET2); > + > dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index); > } > -- 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
Hallo
Bewerben Sie sich für ein Darlehen bei 3% Antwort auf diese E-Mail für mehr Info -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: dummy_hcd: Fix wrong port status macros in dummy_hub_control()
On Mon, Mar 20, 2017 at 10:12:55AM -0400, Alan Stern wrote:
> > @@ -2063,12 +2063,11 @@ static int dummy_hub_control(
> > break;
> > case USB_PORT_FEAT_POWER:
> > if (hcd->speed == HCD_USB3) {
> > - if (dum_hcd->port_status & USB_PORT_STAT_POWER)
> > + if (dum_hcd->port_status &
> > USB_SS_PORT_STAT_POWER)
> > dev_dbg(dummy_dev(dum_hcd),
> > "power-off\n");
> > } else
> > - if (dum_hcd->port_status &
> > - USB_SS_PORT_STAT_POWER)
> > + if (dum_hcd->port_status & USB_PORT_STAT_POWER)
> > dev_dbg(dummy_dev(dum_hcd),
> > "power-off\n");
> > /* FALLS THROUGH */
>
> This certainly is not a complete fix. Compare the code here with the
> code for the SetPortFeature case. For one speed we need to set the
> USB_PORT_STAT_POWER bit and for the other speed we need to set the
> USB_SS_PORT_STAT_POWER bit in dum_hcd->port_status. 1 << wValue cannot
> be the correct bit in both cases.
It depends on whether wValue can reflect the two HCDs, and if not, it looks
like a bigger problem.
And an additional selector is needed?
#define USB_PORT_FEAT_POWER_SS 9
Thanks,
Yuyang
--
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
