Re: Query on usb/core/devio.c
On Do, 2018-10-11 at 14:29 -0400, Alan Stern wrote: > On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote: [..] > > We are looking into closing the device instance during normal operation > > i.e.: only open/close device when needed. > > > > However, we still have one particular use-case where our USB device sends > > async notification to USB-host via the above interface. For that, as of > > now, we queue a URB from user-space. But because, the link never enters > > suspend (L2), we receive this async notification. > > > > I am not sure, how this use-case will work, if we open-close device only > > when needed. > > > > Assuming we have PM calls moved from open/close to ioctl or some other > > appropriate method, is the following sequence possible - > > * Queue an URB -> suspend (L2) > > * Device does remote wake & sends async notification > > * URB above returns with that notification > > It won't work like that. When a device goes into suspend there can't > be any outstanding URBs. Exactly. Yet in case the device is active the URB must be kept running. > How about instead having a mechanism whereby your usrspace driver can > tell when the device does a remote wakeup? At that point it could select() and trigger a wake up from resume()? > submit an URB via usbfs and receive the async notification. I am afraid that design includes an inevitable race condition. It works fine for resume(). It fails for suspend(). If you require user space to cancel periodic transfers before the device can suspend, you will introduce a window of at least two seconds between the cancellation and the eventual suspend() during which the device will not work. In fact events may be outright lost. If you want to suspend with user space drivers active, the kernel will have to kill all active URBs originating from user space drivers. And notify user space when the device is resumed. IMHO select() is the syscall designed for that. Regards Oliver
Re: Sabrent USB 3.0 to SSD // "UAS is blacklisted for this device, using usb-storage instead"
On So, 2018-10-14 at 13:40 +0200, Julian Xhokaxhiu wrote: > Dear USB Driver module maintainers, Hi, thank you for the report > Although sometimes, the system "hangs" very rarely, but in an annoying > fashion that makes a bit sluggish the experience, which translates to > weird dmesg errors like these ones: > https://unix.stackexchange.com/questions/441668/debian-usb3-hdd-uas-i-o-errors Just for confirmation: You are seeing these error messages for the current kernel? I am asking because the link is a report about UAS and you write that UAS is not used. > Initially I thought as I'm using an USB 3.0 adapter[0], that maybe the > UAS driver was buggy, but at my own surprise I found out actually that > the UAS driver is not used at all, although the adapter supports it > fine. > > I am currently using it on a Dell Latitude 7480, and when I use > `lsusb` I see that the device is recognized as `JMicron JMS561U` > which, by spec, supports UAS ( see > http://www.jmicron.com/PDF/brief/jms561u.pdf ). > > I am wondering if this device was already tested by anyone of you > already, and if not, if I can be a tester for a patch to enable UAS on > this adapter. I actually cannot find a patch blacklisting the device which according the log you attached must exist. Which kernel are you using? You can certainly test your device with UAS. Regards Oliver
Re: Sabrent USB 3.0 to SSD // "UAS is blacklisted for this device, using usb-storage instead"
Hi Oliver, I'm currently using the latest 4.18.12 mainline ( on Arch https://www.archlinux.org/packages/core/x86_64/linux/ ), and yes you're right I am NOT using UAS at the moment. The link I left is because I noticed those errors on dmesg, and I thought I had it enabled. This is why I am writing to you right now :) I personally think the SSD sometimes hangs because TRIM commands are not sent properly to the adapter. Although I'm not 100% sure, this is why I would like to test UAS. Can you please point me to the right instructions for trying UAS on my adapter? So I can report back the outcome. Also I noticed that is blacklisted because it's detected as ASMedia ( although it's JMicron ) and falls in one of the four cases that checks for speed ( or something like that, I can't find the link to the source code again otherwise I would have pointed to the code line ). Thank you again for your help and best regards, Julian Xhokaxhiu Full Stack Developer, IT Practised (ISCED 4) https://julianxhokaxhiu.com/ On Mon, Oct 15, 2018 at 12:56 PM Oliver Neukum wrote: > > On So, 2018-10-14 at 13:40 +0200, Julian Xhokaxhiu wrote: > > Dear USB Driver module maintainers, > > Hi, > > thank you for the report > > > Although sometimes, the system "hangs" very rarely, but in an annoying > > fashion that makes a bit sluggish the experience, which translates to > > weird dmesg errors like these ones: > > https://unix.stackexchange.com/questions/441668/debian-usb3-hdd-uas-i-o-errors > > Just for confirmation: > You are seeing these error messages for the current kernel? > I am asking because the link is a report about UAS and you write that > UAS is not used. > > > Initially I thought as I'm using an USB 3.0 adapter[0], that maybe the > > UAS driver was buggy, but at my own surprise I found out actually that > > the UAS driver is not used at all, although the adapter supports it > > fine. > > > > I am currently using it on a Dell Latitude 7480, and when I use > > `lsusb` I see that the device is recognized as `JMicron JMS561U` > > which, by spec, supports UAS ( see > > http://www.jmicron.com/PDF/brief/jms561u.pdf ). > > > > I am wondering if this device was already tested by anyone of you > > already, and if not, if I can be a tester for a patch to enable UAS on > > this adapter. > > I actually cannot find a patch blacklisting the device which > according the log you attached must exist. > Which kernel are you using? > > You can certainly test your device with UAS. > > Regards > Oliver >
Re: Query on usb/core/devio.c
On Mon, 15 Oct 2018, Oliver Neukum wrote: > On Do, 2018-10-11 at 14:29 -0400, Alan Stern wrote: > > On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote: > [..] > > > We are looking into closing the device instance during normal operation > > > i.e.: only open/close device when needed. > > > > > > However, we still have one particular use-case where our USB device sends > > > async notification to USB-host via the above interface. For that, as of > > > now, we queue a URB from user-space. But because, the link never enters > > > suspend (L2), we receive this async notification. > > > > > > I am not sure, how this use-case will work, if we open-close device only > > > when needed. > > > > > > Assuming we have PM calls moved from open/close to ioctl or some other > > > appropriate method, is the following sequence possible - > > > * Queue an URB -> suspend (L2) > > > * Device does remote wake & sends async notification > > > * URB above returns with that notification > > > > It won't work like that. When a device goes into suspend there can't > > be any outstanding URBs. > > Exactly. Yet in case the device is active the URB must be kept running. > > > How about instead having a mechanism whereby your usrspace driver can > > tell when the device does a remote wakeup? At that point it could > > select() and trigger a wake up from resume()? Something like that, although usbfs already has a usbdev_poll() routine with fixed semantics. I'm not sure we can change it. Another difficulty is that select() applies to open files, and usbfs currently doesn't allow the device to suspend while the device file is open. It seems that a better approach would be to have an ioctl which would: fail if there are any active user URBs; drop the usbfs PM reference so the device can suspend; block interruptibly until the device resumes; reacquire the PM reference (forcing the device to resume) if the ioctl call is interrupted. > > submit an URB via usbfs and receive the async notification. > > I am afraid that design includes an inevitable race condition. > It works fine for resume(). It fails for suspend(). If you > require user space to cancel periodic transfers before the device > can suspend, you will introduce a window of at least two seconds > between the cancellation and the eventual suspend() during which > the device will not work. In fact events may be outright lost. That "two seconds" value can be changed by the user, all the way down to 0 if necessary. However, we cannot prevent other processes from keeping the device out of suspend or waking it up. > If you want to suspend with user space drivers active, the kernel will > have to kill all active URBs originating from user space drivers. What difference does it make if the URBs are killed by the user instead of the kernel? > And notify user space when the device is resumed. IMHO select() > is the syscall designed for that. Apart from the difficulties mentioned above. Alan Stern
usb: dwc3: dwc3 errors while video streaming with uvc-gadget
Hi Felipe, I am having some issues when attempting to stream 1280x720 uncompressed video @ 10fps over a USB 2.0 High-Speed link. The system setup is: WebCam --- USB 2.0 link ---> x86 Linux Machine running uvc-gadget USB 2.0 link ---> x86 Host Machine running Windows 10. When running this setup, I am experiencing the following: 1. With streaming_maxpacket set to 2048 (2 transactions per microframe) the video will stream for approximately one minute before terminating with "VS request completed with status -18" reported in the kernel logs. 2. With streaming_maxpacket set to 3072 (3 transactions per microframe) the video does not stream at all with "VS request completed with status -18" reported in the error logs. >From trying to analyse what is going on (looking at traces), it looks like the >dwc3 driver is initially forwarding video buffers as expected. Because the >bandwdith of the USB link is greater than the bandiwidth of the video being >transmitted, at some point the dwc3 driver looks for more buffers to transmit >and there aren't any. At this point, it seems to enter a state that is not >recovered from whenever a new buffer becomes available to transmit. I have included a trace and register dump as requested for further analysis. In terms of hardware/software versions for the test setup: Linux machine - Intel n4200 - running Ubuntu 18.04 - kernel version 4.19.0-041900rc8-generic (I updated to this version this morning to make sure I was using the latest dwc3 driver, the same problem exists (with a different error code -104) with the stock Ubuntu 18.04 kernel). Windows machine - Core i5-4570 - Windows 10 Enterprise. Any help with further investigation of this problem would be appreciated? Could this problem be caused by the configuration setup that I'm using for the uvc gadget? Thanks in advance for your help, Regards, Terry uvc_problem.tar.bz2 Description: application/bzip
[PATCH] USB: fix the usbfs flag sanitization for control transfers
Commit 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more") checks the
transfer flags for URBs submitted from userspace via usbfs. However,
the check for whether the USBDEVFS_URB_SHORT_NOT_OK flag should be
allowed for a control transfer was added in the wrong place, before
the code has properly determined the direction of the control
transfer. (Control transfers are special because for them, the
direction is set by the bRequestType byte of the Setup packet rather
than direction bit of the endpoint address.)
This patch moves code which sets up the allow_short flag for control
transfers down after is_in has been set to the correct value.
Signed-off-by: Alan Stern
Reported-and-tested-by: syzbot+24a30223a4b609bb8...@syzkaller.appspotmail.com
Fixes: 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more")
CC: Oliver Neukum
CC:
---
[as1880]
drivers/usb/core/devio.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: usb-4.x/drivers/usb/core/devio.c
===
--- usb-4.x.orig/drivers/usb/core/devio.c
+++ usb-4.x/drivers/usb/core/devio.c
@@ -1474,8 +1474,6 @@ static int proc_do_submiturb(struct usb_
u = 0;
switch (uurb->type) {
case USBDEVFS_URB_TYPE_CONTROL:
- if (is_in)
- allow_short = true;
if (!usb_endpoint_xfer_control(&ep->desc))
return -EINVAL;
/* min 8 byte setup packet */
@@ -1505,6 +1503,8 @@ static int proc_do_submiturb(struct usb_
is_in = 0;
uurb->endpoint &= ~USB_DIR_IN;
}
+ if (is_in)
+ allow_short = true;
snoop(&ps->dev->dev, "control urb: bRequestType=%02x "
"bRequest=%02x wValue=%04x "
"wIndex=%04x wLength=%04x\n",
Working test 5
Did you get my email from last week? Let me know if you have photos for cutting out or retouching? We are an image team who can do editing for your the web store photos, industry photos or portrait photos. Send photos, we will do testing for you to check quality. Waiting for your reply soon. Thanks, Judy
[PATCH 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. I have no HSIC interface board which is supported by upstream kernel, so this patches are only compiled ok, Frieder Schrempf, would you please help me test it on your board? Thanks. 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 | 153 ++--- drivers/usb/chipidea/ci_hdrc_imx.h | 9 +- drivers/usb/chipidea/host.c| 98 + drivers/usb/chipidea/usbmisc_imx.c | 131 ++ include/linux/usb/chipidea.h | 3 + 6 files changed, 376 insertions(+), 19 deletions(-) -- 2.14.1
[PATCH 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
[PATCH 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 | 153 +
drivers/usb/chipidea/ci_hdrc_imx.h | 9 ++-
drivers/usb/chipidea/usbmisc_imx.c | 131 +++
3 files changed, 274 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 09b37c0d075d..d566771fc77a 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -85,6 +85,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 +248,58 @@ 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:
+ if (!IS_ERR(data->pinctrl) &&
+ !IS_ERR(data->pinctrl_hsic_active)) {
+ ret = pinctrl_select_state(data->pinctrl,
+ data->pinctrl_hsic_active);
+ if (ret)
+ dev_err(dev,
+ "hsic_active select failed, err=%d\n",
+ ret);
+ return ret;
+ }
+ break;
+ case CI_HDRC_IMX_HSIC_SUSPEND_EVENT:
+ if (data->usbmisc_data) {
+ ret = imx_usbmisc_hsic_set_connect(data->usbmisc_data);
+ if (ret)
+ dev_err(dev,
+ "hsic_set_connect failed, err=%d\n",
+ ret);
+ return 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 +310,48 @@ 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);
+ data->pinctrl = devm_pinctrl_get(dev);
+ if (IS_ERR(data->pinctrl)) {
+ dev_dbg(dev, "pinctrl get failed, err=%ld\n",
+ PTR_ERR(data->pinctrl));
+ } else {
+ pinctrl_hsic_idle = pinctrl_lookup_state(data->pinctrl, "idle");
+ if (IS_ERR(pinctrl_hsic_idle)) {
+ dev_dbg(dev,
+ "pinctrl_hsic_idle lookup failed, err=%ld\n",
+ PTR_ERR(pinctrl_hsic_idle));
+ } else {
+ 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");
+
[PATCH 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 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
Re: [PATCH 2/4] usb: chipidea: imx: add HSIC support
Hi Peter,
I love your patch! Yet something to improve:
[auto build test ERROR on peter.chen-usb/ci-for-usb-next]
[also build test ERROR on v4.19-rc8 next-20181012]
[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/Peter-Chen/usb-chipidea-imx-add-HSIC-support/20181016-130840
base: https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
ci-for-usb-next
config: x86_64-randconfig-x017-201841 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/usb/chipidea/ci_hdrc_imx.c: In function 'ci_hdrc_imx_notify_event':
>> drivers/usb/chipidea/ci_hdrc_imx.c:261:10: error: implicit declaration of
>> function 'pinctrl_select_state'; did you mean 'inc_node_state'?
>> [-Werror=implicit-function-declaration]
ret = pinctrl_select_state(data->pinctrl,
^~~~
inc_node_state
drivers/usb/chipidea/ci_hdrc_imx.c: In function 'ci_hdrc_imx_probe':
drivers/usb/chipidea/ci_hdrc_imx.c:317:18: error: implicit declaration of
function 'devm_pinctrl_get'; did you mean 'devm_clk_get'?
[-Werror=implicit-function-declaration]
data->pinctrl = devm_pinctrl_get(dev);
^~~~
devm_clk_get
drivers/usb/chipidea/ci_hdrc_imx.c:317:16: warning: assignment makes pointer
from integer without a cast [-Wint-conversion]
data->pinctrl = devm_pinctrl_get(dev);
^
>> drivers/usb/chipidea/ci_hdrc_imx.c:322:23: error: implicit declaration of
>> function 'pinctrl_lookup_state'; did you mean 'inc_node_state'?
>> [-Werror=implicit-function-declaration]
pinctrl_hsic_idle = pinctrl_lookup_state(data->pinctrl, "idle");
^~~~
inc_node_state
drivers/usb/chipidea/ci_hdrc_imx.c:322:21: warning: assignment makes pointer
from integer without a cast [-Wint-conversion]
pinctrl_hsic_idle = pinctrl_lookup_state(data->pinctrl, "idle");
^
drivers/usb/chipidea/ci_hdrc_imx.c:338:29: warning: assignment makes pointer
from integer without a cast [-Wint-conversion]
data->pinctrl_hsic_active = pinctrl_lookup_state(data->pinctrl,
^
cc1: some warnings being treated as errors
vim +261 drivers/usb/chipidea/ci_hdrc_imx.c
250
251 static int ci_hdrc_imx_notify_event(struct ci_hdrc *ci, unsigned int
event)
252 {
253 struct device *dev = ci->dev->parent;
254 struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
255 int ret = 0;
256
257 switch (event) {
258 case CI_HDRC_IMX_HSIC_ACTIVE_EVENT:
259 if (!IS_ERR(data->pinctrl) &&
260 !IS_ERR(data->pinctrl_hsic_active)) {
> 261 ret = pinctrl_select_state(data->pinctrl,
262 data->pinctrl_hsic_active);
263 if (ret)
264 dev_err(dev,
265 "hsic_active select failed,
err=%d\n",
266 ret);
267 return ret;
268 }
269 break;
270 case CI_HDRC_IMX_HSIC_SUSPEND_EVENT:
271 if (data->usbmisc_data) {
272 ret =
imx_usbmisc_hsic_set_connect(data->usbmisc_data);
273 if (ret)
274 dev_err(dev,
275 "hsic_set_connect failed,
err=%d\n",
276 ret);
277 return ret;
278 }
279 break;
280 default:
281 break;
282 }
283
284 return ret;
285 }
286
287 static int ci_hdrc_imx_probe(struct platform_device *pdev)
288 {
289 struct ci_hdrc_imx_data *data;
290 struct ci_hdrc_platform_data pdata = {
291 .name = dev_name(&pdev->dev),
292 .capoffset = DEF_CAPOFFSET,
293 .notify_event = ci_hdrc_imx_notify_event,
294 };
295 int ret;
296 const struct of_device_id *of_id;
297 const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
298 struct device_node *np = pdev->dev.of_node;
299 struct device *dev = &pdev->dev;
300 struct pinctrl_state *pinctrl_hsic_idle;
301
302 of_id = of_match_device(ci_hdrc_imx_dt_ids, dev);
303 if (!of_id)
304 return -ENODEV
RE: [PATCH 2/4] usb: chipidea: imx: add HSIC support
> Hi Peter,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on peter.chen-usb/ci-for-usb-next] [also build test
> ERROR
> on v4.19-rc8 next-20181012] [if your patch is applied to the wrong git tree,
> please
> drop us a note to help improve the system]
>
> url:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com
> %2F0day-ci%2Flinux%2Fcommits%2FPeter-Chen%2Fusb-chipidea-imx-add-HSIC-
> support%2F20181016-
> 130840&data=02%7C01%7Cpeter.chen%40nxp.com%7C50f2cf2d6d5341bf72
> cc08d6332ba794%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63675
> 2662551616821&sdata=clbCGj%2BrgTz56IKDM0DVVyL3e4q79FsCv3vn%2F7
> TSrQI%3D&reserved=0
> base:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.o
> rg%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpeter.chen%2Fusb.git&data
> =02%7C01%7Cpeter.chen%40nxp.com%7C50f2cf2d6d5341bf72cc08d6332ba794
> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636752662551616821
> &sdata=6Bp7JvbXAsJ%2FGZCOn0VmtZQSnWUCYhgqlbG8ZrbzBoE%3D&a
> mp;reserved=0 ci-for-usb-next
> config: x86_64-randconfig-x017-201841 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
Will fix it by adding #include , it is strange I did
not meet this error.
Peter
> All errors (new ones prefixed by >>):
>
>drivers/usb/chipidea/ci_hdrc_imx.c: In function 'ci_hdrc_imx_notify_event':
> >> drivers/usb/chipidea/ci_hdrc_imx.c:261:10: error: implicit
> >> declaration of function 'pinctrl_select_state'; did you mean
> >> 'inc_node_state'? [-Werror=implicit-function-declaration]
>ret = pinctrl_select_state(data->pinctrl,
> ^~~~
> inc_node_state
>drivers/usb/chipidea/ci_hdrc_imx.c: In function 'ci_hdrc_imx_probe':
>drivers/usb/chipidea/ci_hdrc_imx.c:317:18: error: implicit declaration of
> function
> 'devm_pinctrl_get'; did you mean 'devm_clk_get'? [-Werror=implicit-function-
> declaration]
> data->pinctrl = devm_pinctrl_get(dev);
> ^~~~
> devm_clk_get
>drivers/usb/chipidea/ci_hdrc_imx.c:317:16: warning: assignment makes
> pointer
> from integer without a cast [-Wint-conversion]
> data->pinctrl = devm_pinctrl_get(dev);
>^
> >> drivers/usb/chipidea/ci_hdrc_imx.c:322:23: error: implicit
> >> declaration of function 'pinctrl_lookup_state'; did you mean
> >> 'inc_node_state'? [-Werror=implicit-function-declaration]
> pinctrl_hsic_idle = pinctrl_lookup_state(data->pinctrl, "idle");
> ^~~~
> inc_node_state
>drivers/usb/chipidea/ci_hdrc_imx.c:322:21: warning: assignment makes
> pointer
> from integer without a cast [-Wint-conversion]
> pinctrl_hsic_idle = pinctrl_lookup_state(data->pinctrl, "idle");
> ^
>drivers/usb/chipidea/ci_hdrc_imx.c:338:29: warning: assignment makes
> pointer
> from integer without a cast [-Wint-conversion]
> data->pinctrl_hsic_active = pinctrl_lookup_state(data->pinctrl,
> ^
>cc1: some warnings being treated as errors
>
> vim +261 drivers/usb/chipidea/ci_hdrc_imx.c
>
>250
>251static int ci_hdrc_imx_notify_event(struct ci_hdrc *ci,
> unsigned int event)
>252{
>253struct device *dev = ci->dev->parent;
>254struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
>255int ret = 0;
>256
>257switch (event) {
>258case CI_HDRC_IMX_HSIC_ACTIVE_EVENT:
>259if (!IS_ERR(data->pinctrl) &&
>260!IS_ERR(data->pinctrl_hsic_active)) {
> > 261ret =
> pinctrl_select_state(data->pinctrl,
>262
> data->pinctrl_hsic_active);
>263if (ret)
>264dev_err(dev,
>265"hsic_active select
> failed, err=%d\n",
>266ret);
>267return ret;
>268}
>269break;
>270case CI_HDRC_IMX_HSIC_SUSPEND_EVENT:
>271if (data->usbmisc_data) {
>272ret = imx_usbmisc_hsic_set_connect(data-
> >usbmisc_data);
>273if (ret)
>274dev_err(dev,
>275"hsic_set_connect
> failed, err=%d\n",
>276ret);
>277return ret;
>278
[PATCH] usb: host: ohci-at91: fix request of irq for optional gpio
atmel,oc-gpio is optional. Request it's irq only when atmel,oc is set
in device tree.
devm_gpiod_get_index_optional returns NULL if -ENOENT. Check its
return value for NULL before error, because it is more probably that
atmel,oc is not set.
This fixes the following errors on boards where atmel,oc is not set in
device tree:
[0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
[0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
[0.97] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
Signed-off-by: Tudor Ambarus
---
Based on https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git,
usb-next branch.
drivers/usb/host/ohci-at91.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index e98673954020..ec6739ef3129 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -551,6 +551,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
pdata->overcurrent_pin[i] =
devm_gpiod_get_index_optional(&pdev->dev, "atmel,oc",
i, GPIOD_IN);
+ if (!pdata->overcurrent_pin[i])
+ continue;
if (IS_ERR(pdata->overcurrent_pin[i])) {
err = PTR_ERR(pdata->overcurrent_pin[i]);
dev_err(&pdev->dev, "unable to claim gpio
\"overcurrent\": %d\n", err);
--
2.9.4
Re: [PATCH] usb: host: ohci-at91: fix request of irq for optional gpio
On 15/10/2018 at 10:34, Tudor Ambarus - M18064 wrote:
atmel,oc-gpio is optional. Request it's irq only when atmel,oc is set
in device tree.
devm_gpiod_get_index_optional returns NULL if -ENOENT. Check its
return value for NULL before error, because it is more probably that
atmel,oc is not set.
This fixes the following errors on boards where atmel,oc is not set in
device tree:
[0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
[0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
[0.97] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
Signed-off-by: Tudor Ambarus
Yes, indeed:
Acked-by: Nicolas Ferre
Thanks, best regards,
Nicolas
---
Based on https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git,
usb-next branch.
drivers/usb/host/ohci-at91.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index e98673954020..ec6739ef3129 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -551,6 +551,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
pdata->overcurrent_pin[i] =
devm_gpiod_get_index_optional(&pdev->dev, "atmel,oc",
i, GPIOD_IN);
+ if (!pdata->overcurrent_pin[i])
+ continue;
if (IS_ERR(pdata->overcurrent_pin[i])) {
err = PTR_ERR(pdata->overcurrent_pin[i]);
dev_err(&pdev->dev, "unable to claim gpio \"overcurrent\":
%d\n", err);
--
Nicolas Ferre
[PATCH v2] usb: host: ohci-at91: fix request of irq for optional gpio
atmel,oc-gpio is optional. Request its irq only when atmel,oc is set
in device tree.
devm_gpiod_get_index_optional returns NULL if -ENOENT. Check its
return value for NULL before error, because it is more probable that
atmel,oc is not set.
This fixes the following errors on boards where atmel,oc is not set in
device tree:
[0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
[0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
[0.97] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
Signed-off-by: Tudor Ambarus
---
v2: fix typos in commit message s/it's/its, s/probably/probable
Based on https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git,
usb-next branch.
drivers/usb/host/ohci-at91.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index e98673954020..ec6739ef3129 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -551,6 +551,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
pdata->overcurrent_pin[i] =
devm_gpiod_get_index_optional(&pdev->dev, "atmel,oc",
i, GPIOD_IN);
+ if (!pdata->overcurrent_pin[i])
+ continue;
if (IS_ERR(pdata->overcurrent_pin[i])) {
err = PTR_ERR(pdata->overcurrent_pin[i]);
dev_err(&pdev->dev, "unable to claim gpio
\"overcurrent\": %d\n", err);
--
2.9.4
Re: [PATCH v2] usb: host: ohci-at91: fix request of irq for optional gpio
On 15/10/2018 at 11:00, Tudor Ambarus - M18064 wrote:
atmel,oc-gpio is optional. Request its irq only when atmel,oc is set
in device tree.
devm_gpiod_get_index_optional returns NULL if -ENOENT. Check its
return value for NULL before error, because it is more probable that
atmel,oc is not set.
This fixes the following errors on boards where atmel,oc is not set in
device tree:
[0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
[0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
[0.97] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
Signed-off-by: Tudor Ambarus
As for v1 (patchwork friendly addition):
Acked-by: Nicolas Ferre
Bye,
Nicolas
---
v2: fix typos in commit message s/it's/its, s/probably/probable
Based on https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git,
usb-next branch.
drivers/usb/host/ohci-at91.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index e98673954020..ec6739ef3129 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -551,6 +551,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
*pdev)
pdata->overcurrent_pin[i] =
devm_gpiod_get_index_optional(&pdev->dev, "atmel,oc",
i, GPIOD_IN);
+ if (!pdata->overcurrent_pin[i])
+ continue;
if (IS_ERR(pdata->overcurrent_pin[i])) {
err = PTR_ERR(pdata->overcurrent_pin[i]);
dev_err(&pdev->dev, "unable to claim gpio \"overcurrent\":
%d\n", err);
--
Nicolas Ferre
Can we just remove the sw_lpm_support from current xhci driver?
Hi: I am recently reading the LPM related code in xhci driver, and I find that the xhci->sw_lpm_support is not really used, but I am not sure whether we should remove it or not? Any ideas, Thanks. Regards Zengtao
Re: [RFC] usb: chipidea: Add minimal support for HSIC interface on i.MX6QDL
On 12.10.2018 03:19, Peter Chen wrote: Thanks, I should do it earlier, I could not find a suitable board with HSIC support at mainline kernel. It is very kind that you could help on it and test function at real board. My suggestion is follow all flows in Link [2] since we need to cover suspend/resume and remote wakeup. It seems like power management and other things in the linux-imx kernel are not fully implemented in mainline so there are quite a few differences. My knowledge of USB, etc. is very limited, so I guess this is currently beyond my skills. Can you or someone else provide a patch to get started? I could help with testing, reviewing, etc. Ok, I will supply the patch, and you could add your dts changes as well as testing. Thanks. Ok, great. Just let me know when you have something that is ready for testing and I will give it a try on my setup. Thanks, Frieder
Re: Can we just remove the sw_lpm_support from current xhci driver?
On 15.10.2018 12:35, Zengtao (B) wrote: Hi: I am recently reading the LPM related code in xhci driver, and I find that the xhci->sw_lpm_support is not really used, but I am not sure whether we should remove it or not? Any ideas, Thanks. I think it was used to prevent LPM in pre-0.96 xHC controllers. Now driver only supports HW LPM for 1.0 and later controllers, so xhci->sw_lpm_support doesn't really do anything. You can send a patch removing it Thanks -Mathias
Re: [PATCH 2/8] usbnet: smsc95xx: add kconfig for turbo mode
Ben Dooks writes: > Add a configuration option for the default state of turbo mode > on the smsc95xx networking driver. Some systems it is better > to default this to off as it causes significant increases in > soft-irq load. So there is already a module option allowing you to change this, using e.g kernel command line or kmod config files. It's even writable, taking effect on the next netdev open, so you can change it at runtime without reloading the module. What good does this new build-time setting do, except causing confusion wrt driver defaults? Note also that the smsc95xx and smsc75xx drivers are pretty similar. Both have the same turbo_mode setting. If you change the defaults, then they should at least be kept in sync to cause as little confusion as possible.. Bjørn
[PATCH] usb: gadget: f_fs: add the support for alternate interface setting
In FFS the support for multiple alternate interface settings are not present.
This patch implements the due support. The user application is required to
write interface descriptors to ep0 file of function fs, one for each alternate
interface setting of the same interface, with bAlternateSetting set to different
alt setting values. The order of interface descriptors associated with different
alternate interface settings is same as mentioned by the usb standard. For
example, interface descriptor with alt-setting as 0, followed by it's endpoint
descriptors, then interface descriptor of alt-setting 1, followed by endpoint
descriptors of this alternate interface settings, and so on.
Since alternate setting support is implemented, ffs_func_get_alt function is
also implemented to get alternate interface settings.
Signed-off-by: Parikshit Pareek
---
drivers/usb/gadget/function/f_fs.c | 304 ++---
1 file changed, 253 insertions(+), 51 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 3ada83d..1986c51 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -88,7 +88,6 @@ static struct ffs_function *ffs_func_from_usb(struct
usb_function *f)
static void ffs_func_eps_disable(struct ffs_function *func);
-static int __must_check ffs_func_eps_enable(struct ffs_function *func);
static int ffs_func_bind(struct usb_configuration *,
struct usb_function *);
@@ -1868,46 +1867,6 @@ static void ffs_func_eps_disable(struct ffs_function
*func)
spin_unlock_irqrestore(&func->ffs->eps_lock, flags);
}
-static int ffs_func_eps_enable(struct ffs_function *func)
-{
- struct ffs_data *ffs = func->ffs;
- struct ffs_ep *ep = func->eps;
- struct ffs_epfile *epfile = ffs->epfiles;
- unsigned count= ffs->eps_count;
- unsigned long flags;
- int ret = 0;
-
- spin_lock_irqsave(&func->ffs->eps_lock, flags);
- while(count--) {
- ep->ep->driver_data = ep;
-
- ret = config_ep_by_speed(func->gadget, &func->function, ep->ep);
- if (ret) {
- pr_err("%s: config_ep_by_speed(%s) returned %d\n",
- __func__, ep->ep->name, ret);
- break;
- }
-
- ret = usb_ep_enable(ep->ep);
- if (likely(!ret)) {
- epfile->ep = ep;
- epfile->in = usb_endpoint_dir_in(ep->ep->desc);
- epfile->isoc = usb_endpoint_xfer_isoc(ep->ep->desc);
- } else {
- break;
- }
-
- ++ep;
- ++epfile;
- }
-
- wake_up_interruptible(&ffs->wait);
- spin_unlock_irqrestore(&func->ffs->eps_lock, flags);
-
- return ret;
-}
-
-
/* Parsing and building descriptors and strings */
/*
@@ -1966,7 +1925,10 @@ static int __must_check ffs_do_single_desc(char *data,
unsigned len,
pr_vdebug("invalid entity's value\n"); \
return -EINVAL; \
} \
- ret = entity(FFS_ ##type, &val, _ds, priv); \
+ if (entity) \
+ ret = entity(FFS_ ##type, &val, _ds, priv); \
+ else\
+ ret = 0;\
if (unlikely(ret < 0)) {\
pr_debug("entity " #type "(%02x); ret = %d\n", \
(val), ret); \
@@ -2100,6 +2062,67 @@ static int __must_check ffs_do_descs(unsigned count,
char *data, unsigned len,
}
}
+static int do_function_enable_interface(enum ffs_entity_type type, u8 *valuep,
+ struct usb_descriptor_header *desc,
+ void *priv);
+
+static int do_function_disable_interface(enum ffs_entity_type type, u8 *valuep,
+ struct usb_descriptor_header *desc,
+ void *priv);
+
+static int __must_check ffs_do_descs_alt_intf(unsigned int count, char *data,
+ unsigned int len, unsigned int intf,
+ unsigned int alt, void *priv)
+{
+ const unsigned int _len = len;
+ unsigned long num = 0;
+ struct usb_descriptor_header *_ds;
+ struct usb_interface_descriptor *idecs;
+ ffs_entity_callback entity = NULL;
+
+ ENTER();
+
+ for (;;) {
+ int ret;
+
+
[PATCH v2] phy: phy-pxa-usb: add a new driver
Turned from arch/arm/mach-mmp/devices.c into a proper PHY driver, so that in can be instantiated from a DT. Acked-by: Kishon Vijay Abraham I Signed-off-by: Lubomir Rintel --- Greg, please include this in the USB tree. Changes to mv-ehci driver that are already in can utilize this and it got an Ack from the PHY maintainer. Changes since v1: - None, just added Kishon's Ack Thanks, Lubo drivers/phy/marvell/Kconfig | 11 + drivers/phy/marvell/Makefile | 1 + drivers/phy/marvell/phy-pxa-usb.c | 345 ++ 3 files changed, 357 insertions(+) create mode 100644 drivers/phy/marvell/phy-pxa-usb.c diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig index 68e321225400..6fb4b56e4c14 100644 --- a/drivers/phy/marvell/Kconfig +++ b/drivers/phy/marvell/Kconfig @@ -59,3 +59,14 @@ config PHY_PXA_28NM_USB2 The PHY driver will be used by Marvell udc/ehci/otg driver. To compile this driver as a module, choose M here. + +config PHY_PXA_USB + tristate "Marvell PXA USB PHY Driver" + depends on ARCH_PXA || ARCH_MMP + select GENERIC_PHY + help + Enable this to support Marvell PXA USB PHY driver for Marvell + SoC. This driver will do the PHY initialization and shutdown. + The PHY driver will be used by Marvell udc/ehci/otg driver. + + To compile this driver as a module, choose M here. diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile index 5c3ec5d10e0d..3975b144f8ec 100644 --- a/drivers/phy/marvell/Makefile +++ b/drivers/phy/marvell/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY)+= phy-mvebu-cp110-comphy.o obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o obj-$(CONFIG_PHY_PXA_28NM_HSIC)+= phy-pxa-28nm-hsic.o obj-$(CONFIG_PHY_PXA_28NM_USB2)+= phy-pxa-28nm-usb2.o +obj-$(CONFIG_PHY_PXA_USB) += phy-pxa-usb.o diff --git a/drivers/phy/marvell/phy-pxa-usb.c b/drivers/phy/marvell/phy-pxa-usb.c new file mode 100644 index ..87ff7550b912 --- /dev/null +++ b/drivers/phy/marvell/phy-pxa-usb.c @@ -0,0 +1,345 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2011 Marvell International Ltd. All rights reserved. + * Copyright (C) 2018 Lubomir Rintel + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +/* phy regs */ +#define UTMI_REVISION 0x0 +#define UTMI_CTRL 0x4 +#define UTMI_PLL 0x8 +#define UTMI_TX0xc +#define UTMI_RX0x10 +#define UTMI_IVREF 0x14 +#define UTMI_T00x18 +#define UTMI_T10x1c +#define UTMI_T20x20 +#define UTMI_T30x24 +#define UTMI_T40x28 +#define UTMI_T50x2c +#define UTMI_RESERVE 0x30 +#define UTMI_USB_INT 0x34 +#define UTMI_DBG_CTL 0x38 +#define UTMI_OTG_ADDON 0x3c + +/* For UTMICTRL Register */ +#define UTMI_CTRL_USB_CLK_EN(1 << 31) +/* pxa168 */ +#define UTMI_CTRL_SUSPEND_SET1 (1 << 30) +#define UTMI_CTRL_SUSPEND_SET2 (1 << 29) +#define UTMI_CTRL_RXBUF_PDWN(1 << 24) +#define UTMI_CTRL_TXBUF_PDWN(1 << 11) + +#define UTMI_CTRL_INPKT_DELAY_SHIFT 30 +#define UTMI_CTRL_INPKT_DELAY_SOF_SHIFT28 +#define UTMI_CTRL_PU_REF_SHIFT 20 +#define UTMI_CTRL_ARC_PULLDN_SHIFT 12 +#define UTMI_CTRL_PLL_PWR_UP_SHIFT 1 +#define UTMI_CTRL_PWR_UP_SHIFT 0 + +/* For UTMI_PLL Register */ +#define UTMI_PLL_PLLCALI12_SHIFT 29 +#define UTMI_PLL_PLLCALI12_MASK(0x3 << 29) + +#define UTMI_PLL_PLLVDD18_SHIFT27 +#define UTMI_PLL_PLLVDD18_MASK (0x3 << 27) + +#define UTMI_PLL_PLLVDD12_SHIFT25 +#define UTMI_PLL_PLLVDD12_MASK (0x3 << 25) + +#define UTMI_PLL_CLK_BLK_EN_SHIFT 24 +#define CLK_BLK_EN (0x1 << 24) +#define PLL_READY (0x1 << 23) +#define KVCO_EXT(0x1 << 22) +#define VCOCAL_START(0x1 << 21) + +#define UTMI_PLL_KVCO_SHIFT15 +#define UTMI_PLL_KVCO_MASK (0x7 << 15) + +#define UTMI_PLL_ICP_SHIFT 12 +#define UTMI_PLL_ICP_MASK (0x7 << 12) + +#define UTMI_PLL_FBDIV_SHIFT4 +#define UTMI_PLL_FBDIV_MASK (0xFF << 4) + +#define UTMI_PLL_REFDIV_SHIFT 0 +#define UTMI_PLL_REFDIV_MASK(0xF << 0) + +/* For UTMI_TX Register */ +#define UTMI_TX_REG_EXT_FS_RCAL_SHIFT 27 +#define UTMI_TX_REG_EXT_FS_RCAL_MASK
Re: WARNING in usb_submit_urb (3)
On Fri, 12 Oct 2018, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:9dcd936c5312 Merge tag 'for-4.19/dm-fixes-4' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=123b8da140
> kernel config: https://syzkaller.appspot.com/x/.config?x=88e9a8a39dc0be2d
> dashboard link: https://syzkaller.appspot.com/bug?extid=24a30223a4b609bb802e
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1388899140
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1476e5e640
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+24a30223a4b609bb8...@syzkaller.appspotmail.com
>
> IPVS: ftp: loaded support on port[0] = 21
> [ cut here ]
> usb usb7: BOGUS urb flags, 1 --> 0
> WARNING: CPU: 0 PID: 5828 at drivers/usb/core/urb.c:503
> usb_submit_urb+0x717/0x14e0 drivers/usb/core/urb.c:502
> Kernel panic - not syncing: panic_on_warn set ...
This should have been fixed by commit 7a68d9fb8510 ("USB: usbdevfs:
sanitize flags more"). Was that commit not present in the kernel you
tested?
Alan Stern
Re: [PATCH v2] usb: host: ohci-at91: fix request of irq for optional gpio
On Mon, 15 Oct 2018 tudor.amba...@microchip.com wrote:
> atmel,oc-gpio is optional. Request its irq only when atmel,oc is set
> in device tree.
>
> devm_gpiod_get_index_optional returns NULL if -ENOENT. Check its
> return value for NULL before error, because it is more probable that
> atmel,oc is not set.
>
> This fixes the following errors on boards where atmel,oc is not set in
> device tree:
> [0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
> [0.96] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
> [0.97] at91_ohci 50.ohci: failed to request gpio "overcurrent" IRQ
>
> Signed-off-by: Tudor Ambarus
> ---
> v2: fix typos in commit message s/it's/its, s/probably/probable
>
> Based on https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git,
> usb-next branch.
>
> drivers/usb/host/ohci-at91.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index e98673954020..ec6739ef3129 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -551,6 +551,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device
> *pdev)
> pdata->overcurrent_pin[i] =
> devm_gpiod_get_index_optional(&pdev->dev, "atmel,oc",
> i, GPIOD_IN);
> + if (!pdata->overcurrent_pin[i])
> + continue;
> if (IS_ERR(pdata->overcurrent_pin[i])) {
> err = PTR_ERR(pdata->overcurrent_pin[i]);
> dev_err(&pdev->dev, "unable to claim gpio
> \"overcurrent\": %d\n", err);
Acked-by: Alan Stern
Re: WARNING in usb_submit_urb (3)
On Mon, Oct 15, 2018 at 5:22 PM, Alan Stern wrote:
> On Fri, 12 Oct 2018, syzbot wrote:
>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:9dcd936c5312 Merge tag 'for-4.19/dm-fixes-4' of git://git...
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=123b8da140
>> kernel config: https://syzkaller.appspot.com/x/.config?x=88e9a8a39dc0be2d
>> dashboard link: https://syzkaller.appspot.com/bug?extid=24a30223a4b609bb802e
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1388899140
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1476e5e640
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+24a30223a4b609bb8...@syzkaller.appspotmail.com
>>
>> IPVS: ftp: loaded support on port[0] = 21
>> [ cut here ]
>> usb usb7: BOGUS urb flags, 1 --> 0
>> WARNING: CPU: 0 PID: 5828 at drivers/usb/core/urb.c:503
>> usb_submit_urb+0x717/0x14e0 drivers/usb/core/urb.c:502
>> Kernel panic - not syncing: panic_on_warn set ...
>
> This should have been fixed by commit 7a68d9fb8510 ("USB: usbdevfs:
> sanitize flags more"). Was that commit not present in the kernel you
> tested?
The commit is there, AFAICT. This must be a different issue.
Re: usbip_vudc: BUG kmalloc-2048 (Not tainted): Poison overwritten
On 10/13/2018 11:37 AM, Randy Dunlap wrote: > Kernel 4.19-rc7, on x86_64: > > Load usbip_vudc module, then unload (rmmod) it. > Load it again: > Thanks Randy. I am debugging another problem in this path and I will take a look at this one as well. Just quick ack that I saw this. Thanks for reporting the problem. -- Shuah
Re: WARNING in usb_submit_urb (3)
On Mon, 15 Oct 2018, Andrey Konovalov wrote:
> On Mon, Oct 15, 2018 at 5:22 PM, Alan Stern wrote:
> > On Fri, 12 Oct 2018, syzbot wrote:
> >
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit:9dcd936c5312 Merge tag 'for-4.19/dm-fixes-4' of
> >> git://git...
> >> git tree: upstream
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=123b8da140
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=88e9a8a39dc0be2d
> >> dashboard link:
> >> https://syzkaller.appspot.com/bug?extid=24a30223a4b609bb802e
> >> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1388899140
> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1476e5e640
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+24a30223a4b609bb8...@syzkaller.appspotmail.com
> >>
> >> IPVS: ftp: loaded support on port[0] = 21
> >> [ cut here ]
> >> usb usb7: BOGUS urb flags, 1 --> 0
> >> WARNING: CPU: 0 PID: 5828 at drivers/usb/core/urb.c:503
> >> usb_submit_urb+0x717/0x14e0 drivers/usb/core/urb.c:502
> >> Kernel panic - not syncing: panic_on_warn set ...
> >
> > This should have been fixed by commit 7a68d9fb8510 ("USB: usbdevfs:
> > sanitize flags more"). Was that commit not present in the kernel you
> > tested?
>
> The commit is there, AFAICT. This must be a different issue.
Ah, I see the problem. In fact it is the same issue, but the commit
mentioned above contains an error (is_in gets tested too soon). The
fix is below; can you check it?
Alan Stern
Index: usb-4.x/drivers/usb/core/devio.c
===
--- usb-4.x.orig/drivers/usb/core/devio.c
+++ usb-4.x/drivers/usb/core/devio.c
@@ -1474,8 +1474,6 @@ static int proc_do_submiturb(struct usb_
u = 0;
switch (uurb->type) {
case USBDEVFS_URB_TYPE_CONTROL:
- if (is_in)
- allow_short = true;
if (!usb_endpoint_xfer_control(&ep->desc))
return -EINVAL;
/* min 8 byte setup packet */
@@ -1505,6 +1503,8 @@ static int proc_do_submiturb(struct usb_
is_in = 0;
uurb->endpoint &= ~USB_DIR_IN;
}
+ if (is_in)
+ allow_short = true;
snoop(&ps->dev->dev, "control urb: bRequestType=%02x "
"bRequest=%02x wValue=%04x "
"wIndex=%04x wLength=%04x\n",
Re: WARNING in usb_submit_urb (3)
On Mon, Oct 15, 2018 at 7:12 PM, Alan Stern wrote:
> Ah, I see the problem. In fact it is the same issue, but the commit
> mentioned above contains an error (is_in gets tested too soon). The
> fix is below; can you check it?
You can ask syzbot to do this:
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 244417d0dfd1..ffccd40ea67d 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1474,8 +1474,6 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb
u = 0;
switch (uurb->type) {
case USBDEVFS_URB_TYPE_CONTROL:
- if (is_in)
- allow_short = true;
if (!usb_endpoint_xfer_control(&ep->desc))
return -EINVAL;
/* min 8 byte setup packet */
@@ -1505,6 +1503,8 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb
is_in = 0;
uurb->endpoint &= ~USB_DIR_IN;
}
+ if (is_in)
+ allow_short = true;
snoop(&ps->dev->dev, "control urb: bRequestType=%02x "
"bRequest=%02x wValue=%04x "
"wIndex=%04x wLength=%04x\n",
Re: [PATCH 1/5] dt-bindings: Add Broadcom STB OHCI, EHCI and XHCI binding document
On Wed, Sep 26, 2018 at 06:20:10PM -0400, Al Cooper wrote:
> Add DT bindings document for Broadcom STB USB OHCI, EHCI and
> XHCI drivers.
>
> Signed-off-by: Al Cooper
> ---
> .../devicetree/bindings/usb/brcm,ehci-brcm.txt | 22 +
> .../devicetree/bindings/usb/brcm,ohci-brcm.txt | 22 +
> .../devicetree/bindings/usb/brcm,xhci-brcm.txt | 23
> ++
> 3 files changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/brcm,ehci-brcm.txt
> create mode 100644 Documentation/devicetree/bindings/usb/brcm,ohci-brcm.txt
> create mode 100644 Documentation/devicetree/bindings/usb/brcm,xhci-brcm.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/brcm,ehci-brcm.txt
> b/Documentation/devicetree/bindings/usb/brcm,ehci-brcm.txt
> new file mode 100644
> index ..020b5ec40f5b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/brcm,ehci-brcm.txt
> @@ -0,0 +1,22 @@
> +Broadcom STB USB EHCI controller
> +
> +Required properties:
> +- compatible: should be "brcm,ehci-brcm-v2"
Needs an SoC specific compatible string.
> +- reg: should contain one register range i.e. start and length
> +- interrupts: description of the interrupt line
> +- phys: phandle + phy specifier pair
> + The specifier should be 0 for the OHCI/EHCI PHY and 1 for the XHCI PHY
0 or 1 depends on the phy binding. This binding just needs to say how
many phy specifiers there are.
> +
> +Optional properties:
> +- clocks: A list of phandles for the clocks
Need to say how many and the order.
> +
> +Example:
> +
> +ehci@f0b00300 {
> + compatible = "brcm,ehci-brcm-v2";
> + reg = <0xf0b00300 0xa8>;
> + interrupts = <0x0 0x5a 0x0>;
> + interrupt-names = "usb0_ehci_0";
> + phys = <&usbphy_0 0x0>;
> + clocks = <&usb20>
> +};
Similar comments in the other 2 files.
Re: WARNING in usb_submit_urb (3)
Hello, syzbot has tested the proposed patch and the reproducer did not trigger crash: Reported-and-tested-by: syzbot+24a30223a4b609bb8...@syzkaller.appspotmail.com Tested on: commit: f0a7d1883d9f afs: Fix clearance of reply git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=b3f55cb3dfcc6c33 compiler: gcc (GCC) 8.0.1 20180413 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=164eab9140 Note: testing is done by a robot and is best-effort only.
[PATCH RESEND] usb: gadget: udc: atmel: handle at91sam9rl PMC
The at91sam9rl PMC is not quite the same as the at91sam9g45 one and now has
its own compatible string. Add support for that.
Fixes: 217bace8e548 ("ARM: dts: fix PMC compatible")
Signed-off-by: Alexandre Belloni
Acked-by: Cristian Birsan
---
Hello Greg,
This is an urgent fix that was sent on sep. 10. Can you please assist?
drivers/usb/gadget/udc/atmel_usba_udc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 17147b8c771e..8f267be1745d 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -2017,6 +2017,8 @@ static struct usba_ep * atmel_udc_of_init(struct
platform_device *pdev,
udc->errata = match->data;
udc->pmc = syscon_regmap_lookup_by_compatible("atmel,at91sam9g45-pmc");
+ if (IS_ERR(udc->pmc))
+ udc->pmc =
syscon_regmap_lookup_by_compatible("atmel,at91sam9rl-pmc");
if (IS_ERR(udc->pmc))
udc->pmc =
syscon_regmap_lookup_by_compatible("atmel,at91sam9x5-pmc");
if (udc->errata && IS_ERR(udc->pmc))
--
2.19.1
RE: Can we just remove the sw_lpm_support from current xhci driver?
Hi Mathias: >-Original Message- >From: Mathias Nyman [mailto:mathias.ny...@intel.com] >Sent: Monday, October 15, 2018 8:11 PM >To: Zengtao (B) ; Greg KH > >Cc: linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org >Subject: Re: Can we just remove the sw_lpm_support from current xhci >driver? > >On 15.10.2018 12:35, Zengtao (B) wrote: >> Hi: >> >> I am recently reading the LPM related code in xhci driver, and I find >> that the xhci->sw_lpm_support is not really used, but I am not sure >> whether we should remove it or not? >> >> Any ideas, Thanks. > >I think it was used to prevent LPM in pre-0.96 xHC controllers. >Now driver only supports HW LPM for 1.0 and later controllers, so >xhci->sw_lpm_support doesn't really do anything. > >You can send a patch removing it > Ok, I will send a patch to do it, thanks. >Thanks >-Mathias
[PATCH] xhci: remove the unused sw_lpm_support
It is introduced for the pre-0.96 xHC controllers, and the driver only
support HW LPM for 1.0 and later controllers.It's not actually used now
and is thought not to be used in the future any more, so just remove it.
Acked-by: Mathias Nyman
Signed-off-by: Zeng Tao
---
drivers/usb/host/xhci-mem.c | 20
drivers/usb/host/xhci.c | 3 +--
drivers/usb/host/xhci.h | 2 --
3 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b1f27aa..791c5d8 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2181,23 +2181,11 @@ static void xhci_add_in_port(struct xhci_hcd *xhci,
unsigned int num_ports,
if (major_revision < 0x03 && xhci->num_ext_caps < max_caps)
xhci->ext_caps[xhci->num_ext_caps++] = temp;
- /* Check the host's USB2 LPM capability */
- if ((xhci->hci_version == 0x96) && (major_revision != 0x03) &&
- (temp & XHCI_L1C)) {
+ if ((xhci->hci_version >= 0x100) && (major_revision != 0x03) &&
+(temp & XHCI_HLC)) {
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
- "xHCI 0.96: support USB2 software lpm");
- xhci->sw_lpm_support = 1;
- }
-
- if ((xhci->hci_version >= 0x100) && (major_revision != 0x03)) {
- xhci_dbg_trace(xhci, trace_xhci_dbg_init,
- "xHCI 1.0: support USB2 software lpm");
- xhci->sw_lpm_support = 1;
- if (temp & XHCI_HLC) {
- xhci_dbg_trace(xhci, trace_xhci_dbg_init,
- "xHCI 1.0: support USB2 hardware lpm");
- xhci->hw_lpm_support = 1;
- }
+ "xHCI 1.0: support USB2 hardware lpm");
+ xhci->hw_lpm_support = 1;
}
port_offset--;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 0420eef..d565d5a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4372,8 +4372,7 @@ static int xhci_update_device(struct usb_hcd *hcd, struct
usb_device *udev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
int portnum = udev->portnum - 1;
- if (hcd->speed >= HCD_USB3 || !xhci->sw_lpm_support ||
- !udev->lpm_capable)
+ if (hcd->speed >= HCD_USB3 || !udev->lpm_capable)
return 0;
/* we only support lpm for non-hub device connected to root hub yet */
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 6230a57..746129d 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1854,8 +1854,6 @@ struct xhci_hcd {
struct xhci_port*hw_ports;
struct xhci_hub usb2_rhub;
struct xhci_hub usb3_rhub;
- /* support xHCI 0.96 spec USB2 software LPM */
- unsignedsw_lpm_support:1;
/* support xHCI 1.0 spec USB2 hardware LPM */
unsignedhw_lpm_support:1;
/* cached usb2 extened protocol capabilites */
--
2.7.4
