I NEED YOUR HELP URGENTLY!!!
Compliment of the day to you. I am Gen.Kelvin W Howard, I am sending this brief letter to solicit your partnership of Sixteen Million Two Hundred Thousand United States Dollars ($16,200,000). I shall send you more information and procedures when I receive positive response from you.Best Regards, CONTACT ME: kivenhow...@gmail.com Gen.Kelvin W Howard --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Logitech G27 leds no more supported
SOLVED that's due to this is compiled as modules: CONFIG_LEDS_SYSCON CONFIG_LEDS_SYSCON and not as YES option Thnaks ‐‐‐ Original Message ‐‐‐ Le dimanche 21 octobre 2018 08:16, a écrit : > There is no switch in G27, it's a pure PC wheel, and leds are not recognized > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > Le samedi 20 octobre 2018 01:03, Simon Wood si...@mungewell.org a écrit : > > > On Fri, October 19, 2018 4:46 pm, Simon Wood wrote: > > > > > Thanks for the report, and yes it does seem broken. I tried on > > > 4.17.0-rc5+ > > > and it seems that the 'hid-logitech' module does not know the device ID of > > > the G29 anymore. > > > > Oh, how easily we forget things... there's a switch on the top wheel > > (close to LEDs) which changes the wheel into a compatibility mode. > > Flipping this get wheel recognized and working on 4.17.0-rc5+ > > > > root@thevoid:/sys/class/leds# ls > > 0003:046D:C24F.0009::RPM1 0003:046D:C24F.0009::RPM4 input3::numlock > > input8::compose input8::scrolllock > > 0003:046D:C24F.0009::RPM2 0003:046D:C24F.0009::RPM5 input3::scrolllock > > input8::kana > > 0003:046D:C24F.0009::RPM3 input3::capslock input8::capslock > > input8::numlock > > root@thevoid:/sys/class/leds# cd 0003\:046D\:C24F.0009\:\:RPM4 > > root@thevoid:/sys/class/leds/0003:046D:C24F.0009::RPM4# ls > > brightness device max_brightness power subsystem trigger uevent > > root@thevoid:/sys/class/leds/0003:046D:C24F.0009::RPM4# cat max_brightness > > > > > brightness > > > > -- > > I'll rebuild HEAD to confirm it still works. > > Simon. > > PS. We should maybe pick up that other USB Id.
[PATCH] usb: dwc2: disable power_down on rockchip devices
>From 04fbf78e4e569bf872f1ffcb0a6f9b89569dc913 Mon Sep 17 00:00:00 2001 From: Hal Emmerich Date: Thu, 19 Jul 2018 21:48:08 -0500 Subject: [PATCH] usb: dwc2: disable power_down on rockchip devices The bug would let the usb controller enter partial power down, which was formally known as hibernate, upon boot if nothing was plugged in to the port. Partial power down couldn't be exited properly, so any usb devices plugged in after boot would not be usable. Before the name change, params.hibernation was false by default, so _dwc2_hcd_suspend() would skip entering hibernation. With the rename, _dwc2_hcd_suspend() was changed to use params.power_down to decide whether or not to enter partial power down. Since params.power_down is non-zero by default, it needs to be set to 0 for rockchip devices to restore functionality. This bug was reported in the linux-usb thread: REGRESSION: usb: dwc2: USB device not seen after boot The commit that caused this regression is: 6d23ee9caa6790aea047f9aca7f3c03cb8d96eb6 Signed-off-by: Hal Emmerich Acked-by: Minas Harutyunyan --- drivers/usb/dwc2/params.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c index bf7052e037d6..09292dc977e4 100644 --- a/drivers/usb/dwc2/params.c +++ b/drivers/usb/dwc2/params.c @@ -81,6 +81,7 @@ static void dwc2_set_rk_params(struct dwc2_hsotg *hsotg) p->host_perio_tx_fifo_size = 256; p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT; + p->power_down = 0; } static void dwc2_set_ltq_params(struct dwc2_hsotg *hsotg) -- 2.11.0
[PATCH v2 0/4] usb: chipidea: imx: add HSIC support
Most of NXP (Freescale) i.mx USB part has HSIC support, in this series, we add support for them, it should cover all imx6 and imx7d SoC. Changes for v2: - Compile error reported by kbuild robot [Patch 2/4] - Comment from Frieder Schrempf about code structure [Patch 2/4] - Comment from Fabio about adding example for pinctrl [Patch 4/4] Peter Chen (4): usb: chipidea: add flag for imx hsic implementation usb: chipidea: imx: add HSIC support usb: chipidea: host: override ehci->hub_control doc: usb: ci-hdrc-usb2: Add pinctrl properties for HSIC pin groups .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 1 + drivers/usb/chipidea/ci_hdrc_imx.c | 140 ++--- drivers/usb/chipidea/ci_hdrc_imx.h | 9 +- drivers/usb/chipidea/host.c| 98 +++ drivers/usb/chipidea/usbmisc_imx.c | 130 +++ include/linux/usb/chipidea.h | 3 + 6 files changed, 362 insertions(+), 19 deletions(-) -- 2.14.1
[PATCH v2 2/4] usb: chipidea: imx: add HSIC support
To support imx HSIC, there are some special requirement:
- The HSIC pad is 1.2v, it may need to supply from external
- The data/strobe pin needs to be pulled down first, and after
host mode is initialized, the strobe pin needs to be pulled up
- During the USB suspend/resume, special setting is needed
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c | 140 -
drivers/usb/chipidea/ci_hdrc_imx.h | 9 ++-
drivers/usb/chipidea/usbmisc_imx.c | 130 ++
3 files changed, 260 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 09b37c0d075d..389c3261c4ee 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "ci.h"
#include "ci_hdrc_imx.h"
@@ -85,6 +86,9 @@ struct ci_hdrc_imx_data {
bool supports_runtime_pm;
bool override_phy_control;
bool in_lpm;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pinctrl_hsic_active;
+ struct regulator *hsic_pad_regulator;
/* SoC before i.mx6 (except imx23/imx28) needs three clks */
bool need_three_clks;
struct clk *clk_ipg;
@@ -245,19 +249,49 @@ static void imx_disable_unprepare_clks(struct device *dev)
}
}
+static int ci_hdrc_imx_notify_event(struct ci_hdrc *ci, unsigned int event)
+{
+ struct device *dev = ci->dev->parent;
+ struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+ int ret = 0;
+
+ switch (event) {
+ case CI_HDRC_IMX_HSIC_ACTIVE_EVENT:
+ ret = pinctrl_select_state(data->pinctrl,
+ data->pinctrl_hsic_active);
+ if (ret)
+ dev_err(dev, "hsic_active select failed, err=%d\n",
+ ret);
+ break;
+ case CI_HDRC_IMX_HSIC_SUSPEND_EVENT:
+ ret = imx_usbmisc_hsic_set_connect(data->usbmisc_data);
+ if (ret)
+ dev_err(dev,
+ "hsic_set_connect failed, err=%d\n", ret);
+ break;
+ default:
+ break;
+ }
+
+ return ret;
+}
+
static int ci_hdrc_imx_probe(struct platform_device *pdev)
{
struct ci_hdrc_imx_data *data;
struct ci_hdrc_platform_data pdata = {
.name = dev_name(&pdev->dev),
.capoffset = DEF_CAPOFFSET,
+ .notify_event = ci_hdrc_imx_notify_event,
};
int ret;
const struct of_device_id *of_id;
const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct pinctrl_state *pinctrl_hsic_idle;
- of_id = of_match_device(ci_hdrc_imx_dt_ids, &pdev->dev);
+ of_id = of_match_device(ci_hdrc_imx_dt_ids, dev);
if (!of_id)
return -ENODEV;
@@ -268,19 +302,73 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, data);
- data->usbmisc_data = usbmisc_get_init_data(&pdev->dev);
+ data->usbmisc_data = usbmisc_get_init_data(dev);
if (IS_ERR(data->usbmisc_data))
return PTR_ERR(data->usbmisc_data);
- ret = imx_get_clks(&pdev->dev);
+ if (of_usb_get_phy_mode(dev->of_node) == USBPHY_INTERFACE_MODE_HSIC) {
+ pdata.flags |= CI_HDRC_IMX_IS_HSIC;
+ data->usbmisc_data->hsic = 1;
+ data->pinctrl = devm_pinctrl_get(dev);
+ if (IS_ERR(data->pinctrl)) {
+ dev_err(dev, "pinctrl get failed, err=%ld\n",
+ PTR_ERR(data->pinctrl));
+ return PTR_ERR(data->pinctrl);
+ }
+
+ pinctrl_hsic_idle = pinctrl_lookup_state(data->pinctrl, "idle");
+ if (IS_ERR(pinctrl_hsic_idle)) {
+ dev_err(dev,
+ "pinctrl_hsic_idle lookup failed, err=%ld\n",
+ PTR_ERR(pinctrl_hsic_idle));
+ return PTR_ERR(pinctrl_hsic_idle);
+ }
+
+ ret = pinctrl_select_state(data->pinctrl, pinctrl_hsic_idle);
+ if (ret) {
+ dev_err(dev, "hsic_idle select failed, err=%d\n", ret);
+ return ret;
+ }
+
+ data->pinctrl_hsic_active = pinctrl_lookup_state(data->pinctrl,
+ "active");
+ if (IS_ERR(data->pinctrl_hsic_active)) {
+ dev_err(dev,
+ "pinctrl_hsic_active lookup failed, err=%ld\n",
+ PTR_ERR(data->p
[PATCH v2 4/4] doc: usb: ci-hdrc-usb2: Add pinctrl properties for HSIC pin groups
For USB HSIC, the data and strobe pin needs to be pulled down at default, we consider it as "idle" state. When the USB host is ready to be used, the strobe pin needs to be pulled up, we consider it as "active" state. Signed-off-by: Peter Chen --- Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt index 529e51879fb2..10c8d793ea49 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt @@ -81,6 +81,7 @@ Optional properties: mux state of 1 indicates host mode. - mux-control-names: Shall be "usb_switch" if mux-controls is specified. - pinctrl-names: Names for optional pin modes in "default", "host", "device" + Or names for HSIC "idle" and "active" pin modes. - pinctrl-n: alternate pin modes i.mx specific properties -- 2.14.1
[PATCH v2 1/4] usb: chipidea: add flag for imx hsic implementation
NXP (Freecale) imx HSIC design has some special requirements, add
some flags at host code to handle them.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/host.c | 24
include/linux/usb/chipidea.h | 3 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index d858a82c4f44..d74a13d7c21c 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -28,6 +28,20 @@ struct ehci_ci_priv {
struct regulator *reg_vbus;
};
+/* This function is used to override WKCN, WKDN, and WKOC */
+static void ci_ehci_override_wakeup_flag(struct ehci_hcd *ehci,
+ u32 __iomem *reg, u32 flags, bool set)
+{
+ u32 val = ehci_readl(ehci, reg);
+
+ if (set)
+ val |= flags;
+ else
+ val &= ~flags;
+
+ ehci_writel(ehci, val, reg);
+}
+
static int ehci_ci_portpower(struct usb_hcd *hcd, int portnum, bool enable)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -170,6 +184,11 @@ static int host_start(struct ci_hdrc *ci)
otg->host = &hcd->self;
hcd->self.otg_port = 1;
}
+
+ if (ci->platdata->notify_event &&
+ (ci->platdata->flags & CI_HDRC_IMX_IS_HSIC))
+ ci->platdata->notify_event
+ (ci, CI_HDRC_IMX_HSIC_ACTIVE_EVENT);
}
return ret;
@@ -218,6 +237,8 @@ void ci_hdrc_host_destroy(struct ci_hdrc *ci)
static int ci_ehci_bus_suspend(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+ struct device *dev = hcd->self.controller;
+ struct ci_hdrc *ci = dev_get_drvdata(dev);
int port;
u32 tmp;
@@ -249,6 +270,9 @@ static int ci_ehci_bus_suspend(struct usb_hcd *hcd)
* It needs a short delay between set RS bit and PHCD.
*/
usleep_range(150, 200);
+ if (ci->platdata->flags & CI_HDRC_IMX_IS_HSIC)
+ ci_ehci_override_wakeup_flag(ehci, reg,
+ PORT_WKDISC_E | PORT_WKCONN_E, false);
break;
}
}
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 63758c399e4e..911e05af671e 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -60,9 +60,12 @@ struct ci_hdrc_platform_data {
#define CI_HDRC_OVERRIDE_RX_BURST BIT(11)
#define CI_HDRC_OVERRIDE_PHY_CONTROL BIT(12) /* Glue layer manages phy */
#define CI_HDRC_REQUIRES_ALIGNED_DMA BIT(13)
+#define CI_HDRC_IMX_IS_HSICBIT(14)
enum usb_dr_modedr_mode;
#define CI_HDRC_CONTROLLER_RESET_EVENT 0
#define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
+#define CI_HDRC_IMX_HSIC_ACTIVE_EVENT 2
+#define CI_HDRC_IMX_HSIC_SUSPEND_EVENT 3
int (*notify_event) (struct ci_hdrc *ci, unsigned event);
struct regulator*reg_vbus;
struct usb_otg_caps ci_otg_caps;
--
2.14.1
[PATCH v2 3/4] usb: chipidea: host: override ehci->hub_control
The chipidea controller has some special requirements during
suspend/resume, override common ehci->hub_control to implement
it.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/host.c | 74 +
1 file changed, 74 insertions(+)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index d74a13d7c21c..b8e7d7fe3d53 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -234,6 +234,79 @@ void ci_hdrc_host_destroy(struct ci_hdrc *ci)
host_stop(ci);
}
+/* The below code is based on tegra ehci driver */
+static int ci_ehci_hub_control(
+ struct usb_hcd *hcd,
+ u16 typeReq,
+ u16 wValue,
+ u16 wIndex,
+ char*buf,
+ u16 wLength
+)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+ u32 __iomem *status_reg;
+ u32 temp;
+ unsigned long flags;
+ int retval = 0;
+ struct device *dev = hcd->self.controller;
+ struct ci_hdrc *ci = dev_get_drvdata(dev);
+
+ status_reg = &ehci->regs->port_status[(wIndex & 0xff) - 1];
+
+ spin_lock_irqsave(&ehci->lock, flags);
+
+ if (typeReq == SetPortFeature && wValue == USB_PORT_FEAT_SUSPEND) {
+ temp = ehci_readl(ehci, status_reg);
+ if ((temp & PORT_PE) == 0 || (temp & PORT_RESET) != 0) {
+ retval = -EPIPE;
+ goto done;
+ }
+
+ temp &= ~(PORT_RWC_BITS | PORT_WKCONN_E);
+ temp |= PORT_WKDISC_E | PORT_WKOC_E;
+ ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
+
+ /*
+* If a transaction is in progress, there may be a delay in
+* suspending the port. Poll until the port is suspended.
+*/
+ if (ehci_handshake(ehci, status_reg, PORT_SUSPEND,
+ PORT_SUSPEND, 5000))
+ ehci_err(ehci, "timeout waiting for SUSPEND\n");
+
+ if (ci->platdata->flags & CI_HDRC_IMX_IS_HSIC) {
+ if (ci->platdata->notify_event)
+ ci->platdata->notify_event
+ (ci, CI_HDRC_IMX_HSIC_SUSPEND_EVENT);
+ ci_ehci_override_wakeup_flag(ehci, status_reg,
+ PORT_WKDISC_E | PORT_WKCONN_E, false);
+ }
+
+ set_bit((wIndex & 0xff) - 1, &ehci->suspended_ports);
+ goto done;
+ }
+
+ /*
+* After resume has finished, it needs do some post resume
+* operation for some SoCs.
+*/
+ else if (typeReq == ClearPortFeature &&
+ wValue == USB_PORT_FEAT_C_SUSPEND) {
+
+ /* Make sure the resume has finished, it should be finished */
+ if (ehci_handshake(ehci, status_reg, PORT_RESUME, 0, 25000))
+ ehci_err(ehci, "timeout waiting for resume\n");
+ }
+
+ spin_unlock_irqrestore(&ehci->lock, flags);
+
+ /* Handle the hub control events here */
+ return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+done:
+ spin_unlock_irqrestore(&ehci->lock, flags);
+ return retval;
+}
static int ci_ehci_bus_suspend(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -305,4 +378,5 @@ void ci_hdrc_host_driver_init(void)
ehci_init_driver(&ci_ehci_hc_driver, &ehci_ci_overrides);
orig_bus_suspend = ci_ehci_hc_driver.bus_suspend;
ci_ehci_hc_driver.bus_suspend = ci_ehci_bus_suspend;
+ ci_ehci_hc_driver.hub_control = ci_ehci_hub_control;
}
--
2.14.1
Re: Query on usb/core/devio.c
On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote: > On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote: > > > > The only way to make the ioctl work properly is to have it do a > > > runtime-PM put at the start and then a runtime-PM get before it If and only if you want to do this with one ioctl() If you separate the runtime-PM put and the get, you can do it without the waiting part. > > > returns. This is true regardless of the reason for returning: normal > > > termination, timeout, signal, whatever. Nothing else would be safe. > > > > > > > Will below steps work safely (sometimes pseudo-code/snippets help to > > align)? - > > > > "new" ioctl - > > > > timeout is parameter to ioctl. > > > > /* attempt suspend of device */ > > usb_autosuspend_device(dev); > > > > usb_unlock_device(dev); > > r = wait_event_interruptible_timeout(ps->resume_wait, > > (ps->resume_done == true), timeout * HZ); > > Not exactly. The condition to test here is whether the device has been > suspended, so it's more like this: > > r = wait_event_interruptible_timeout(ps->suspend_wait, > (ps->suspend_done == true), timeout * HZ); > > where ps->suspend_done is set by the runtime_suspend callback. After > this we will do: > > if (r > 0) /* Device suspended before the timeout expired */ > r = wait_event_interruptible(ps->resume_wait, > (ps->resume_done == true)); > > > usb_lock_device(dev); > > > > /* > > * There are 3 possibilities here: > > * 1. Device did suspend and resume (success) > > * 2. Signal was received (failed suspend) > > * 3. Time-out happened (failed suspend) > > 4. Device did suspend but a signal was received before the device > resumed. > > > * In any of above cases, we need to resume device. > > */ > > usb_autoresume_device(dev); Yes and that is the problem. Why do you want to wait for the result of runtime-PM put ? If we need a channel for notifying user space about resume of a device, why wait for the result of suspend instead of using the same channel? > > > > ps->resume_done = false; > > > > "ps->resume_done = true;" will be done by the runtime resume call-back. No. You cannot do that in this way. It needs to be a unified device state or a sequence of multiple suspends and resumes will have strange results. Regards Oliver
[PATCH] USB: misc: appledisplay: add 20" Apple Cinema Display
Add another Apple Cinema Display to the list of supported displays
Signed-off-by: Mattias Jacobsson <2...@mok.nu>
---
drivers/usb/misc/appledisplay.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledisplay.c
index bd539f3058bc..85b48c6ddc7e 100644
--- a/drivers/usb/misc/appledisplay.c
+++ b/drivers/usb/misc/appledisplay.c
@@ -50,6 +50,7 @@ static const struct usb_device_id appledisplay_table[] = {
{ APPLEDISPLAY_DEVICE(0x9219) },
{ APPLEDISPLAY_DEVICE(0x921c) },
{ APPLEDISPLAY_DEVICE(0x921d) },
+ { APPLEDISPLAY_DEVICE(0x9222) },
{ APPLEDISPLAY_DEVICE(0x9236) },
/* Terminating entry */
--
2.19.1
[PATCH 2/2] usb: xhci: fix timeout for transition from RExit to U0
This definition is used by msecs_to_jiffies in milliseconds.
According to the comments, max rexit timeout should be 20ms.
Align with the comments to properly calculate the delay.
Verified on Sunrise Point-LP and Cannon Lake.
Signed-off-by: Aaron Ma
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 6230a578324c..30225c53be1c 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1678,7 +1678,7 @@ struct xhci_bus_state {
* It can take up to 20 ms to transition from RExit to U0 on the
* Intel Lynx Point LP xHCI host.
*/
-#defineXHCI_MAX_REXIT_TIMEOUT (20 * 1000)
+#defineXHCI_MAX_REXIT_TIMEOUT 20
static inline unsigned int hcd_index(struct usb_hcd *hcd)
{
--
2.19.1
[PATCH 1/2] usb: xhci: fix uninitialized completion when USB3 port got wrong status
Realtek USB3.0 Card Reader [0bda:0328] reports wrong port status on
Cannon lake PCH USB3.1 xHCI [8086:a36d] after resume from S3,
after clear port reset it works fine.
Since this device is registered on USB3 roothub at boot,
when port status reports not superspeed, xhci_get_port_status will call
an uninitialized completion in bus_state[0].
Kernel will hang because of NULL pointer.
Restrict the USB2 resume status check in USB2 roothub to fix hang issue.
No harm to initialize USB3 bus_state[0] in case it is called.
Signed-off-by: Aaron Ma
---
drivers/usb/host/xhci-hub.c | 2 +-
drivers/usb/host/xhci-mem.c | 1 +
drivers/usb/host/xhci-ring.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 7e2a531ba321..d30ca6ceffc9 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -876,7 +876,7 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd,
status |= USB_PORT_STAT_SUSPEND;
}
if ((raw_port_status & PORT_PLS_MASK) == XDEV_RESUME &&
- !DEV_SUPERSPEED_ANY(raw_port_status)) {
+ !DEV_SUPERSPEED_ANY(raw_port_status) && 1 == hcd_index(hcd)) {
if ((raw_port_status & PORT_RESET) ||
!(raw_port_status & PORT_PE))
return 0x;
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b1f27aa38b10..dd2ad50c5289 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2539,6 +2539,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
xhci->bus_state[0].resume_done[i] = 0;
xhci->bus_state[1].resume_done[i] = 0;
/* Only the USB 2.0 completions will ever be used. */
+ init_completion(&xhci->bus_state[0].rexit_done[i]);
init_completion(&xhci->bus_state[1].rexit_done[i]);
}
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index f0a99aa0ac58..894d4625b8b9 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1634,7 +1634,7 @@ static void handle_port_status(struct xhci_hcd *xhci,
* RExit to a disconnect state). If so, let the the driver know it's
* out of the RExit state.
*/
- if (!DEV_SUPERSPEED_ANY(portsc) &&
+ if (!DEV_SUPERSPEED_ANY(portsc) && 1 == hcd_index(hcd) &&
test_and_clear_bit(hcd_portnum,
&bus_state->rexit_ports)) {
complete(&bus_state->rexit_done[hcd_portnum]);
--
2.19.1
Re: [PATCH 2/2] usb: xhci: fix timeout for transition from RExit to U0
On Mon, Oct 22, 2018 at 01:08:45AM +0800, Aaron Ma wrote:
> This definition is used by msecs_to_jiffies in milliseconds.
> According to the comments, max rexit timeout should be 20ms.
> Align with the comments to properly calculate the delay.
>
> Verified on Sunrise Point-LP and Cannon Lake.
>
> Signed-off-by: Aaron Ma
> ---
> drivers/usb/host/xhci.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 6230a578324c..30225c53be1c 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1678,7 +1678,7 @@ struct xhci_bus_state {
> * It can take up to 20 ms to transition from RExit to U0 on the
> * Intel Lynx Point LP xHCI host.
> */
> -#define XHCI_MAX_REXIT_TIMEOUT (20 * 1000)
> +#define XHCI_MAX_REXIT_TIMEOUT 20
Can we put the units in the #define itself so that this will be more
obvious in the future? Like XHCI_MAX_REXIT_TIMEOUT_MS?
thanks,
greg k-h
Re: [PATCH 2/2] usb: xhci: fix timeout for transition from RExit to U0
On 10/22/18 2:21 AM, Greg KH wrote: > Can we put the units in the #define itself so that this will be more > obvious in the future? Like XHCI_MAX_REXIT_TIMEOUT_MS? If no other concerns about these 2 patches, I will send V2 of 2nd patch to follow your advice. Thanks, Aaron
