Re: Kernel memory leak on CDC-ACM device plug/unplug
On Mi, 2018-09-19 at 16:11 +0200, Romain Izard wrote: > While trying to debug a memory leak problem, I encountered the following > problem: > > After plugging/unplugging an USB CDC-ACM device, kmemleak reports multiple > copies of the following leak. It is not necessary to open the port for the > leak to happen. Hi, nothing is immediately obvious to me. Could you compile a kernel with CONFIG_DEBUG_KMEMLEAK? Regards Oliver
Re: [PATCH 3/3] usb: host: xhci: return early for xhci_urb_dequeue when removing hcd
On 9/21/2018 4:48 AM, Peter Chen wrote:
When we are removing hcd, the stop endpoint command may be timeout.
To eliminate the timeout, we'd better return early. The related log
for this timeout like below:
[31.208933] hub 3-1:1.0: hub_ext_port_status failed (err = -71)
[31.214972] usb 3-1-port2: cannot reset (err = -71)
[31.219962] usb 3-1-port2: cannot reset (err = -71)
[31.225069] usb 3-1-port2: cannot reset (err = -71)
[31.230018] usb 3-1-port2: Cannot enable. Maybe the USB cable is bad?
[31.236566] usb 3-1-port2: cannot disable (err = -71)
[31.241745] usb 3-1-port2: unable to enumerate USB device
[31.247255] usb 3-1-port2: cannot disable (err = -71)
[31.252422] hub 3-1:1.0: hub_ext_port_status failed (err = -71)
[31.258486] hub 3-1:1.0: hub_ext_port_status failed (err = -71)
[31.264518] hub 3-1:1.0: hub_ext_port_status failed (err = -71)
[31.270649] hub 3-1:1.0: hub_ext_port_status failed (err = -71)
[31.276723] hub 3-1:1.0: hub_ext_port_status failed (err = -71)
[31.282809] usb 3-1: USB disconnect, device number 2
[31.287859] usb 3-1.1: USB disconnect, device number 3
[31.293076] usb 3-1.1: unregistering device
[31.299292] xhci-hcd xhci-hcd.1.auto: remove, state 4
[31.304416] usb usb4: USB disconnect, device number 1
[31.309566] usb 4-1: USB disconnect, device number 2
[31.314589] usb 4-1: unregistering device
[31.316389] usb 3-1: unregistering device
[31.331131] usb usb4: unregistering device
[31.339809] xhci-hcd xhci-hcd.1.auto: USB bus 4 deregistered
[31.345534] xhci-hcd xhci-hcd.1.auto: remove, state 1
[31.350668] usb usb3: USB disconnect, device number 1
[36.407457] xhci-hcd xhci-hcd.1.auto: xHCI host not responding to stop endpoint
command.
[36.423638] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding,
assume dead
[36.436502] usb usb3: unregistering device
[36.445429] xhci-hcd xhci-hcd.1.auto: USB bus 3 deregistered
Signed-off-by: Peter Chen
---
drivers/usb/host/xhci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3113938063fd..1bcf27a9737d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1601,7 +1601,8 @@ static int xhci_urb_dequeue(struct usb_hcd *hcd, struct
urb *urb, int status)
goto err_giveback;
}
- if (xhci->xhc_state & XHCI_STATE_HALTED) {
+ if (xhci->xhc_state & XHCI_STATE_HALTED ||
+ xhci->xhc_state & XHCI_STATE_REMOVING) {
This way this line blends with the branch below, could you indent either
with 2 tabs (I think it's the style preferred in the USB code) or starting the
continuation line under xhci on the previous line.
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
"HC halted, freeing TD manually.");
for (i = urb_priv->num_tds_done;
MBR, Sergei
Re: [PATCH 2/3] usb: host: xhci: return -ESHUTDOWN when removing hcd
On 9/21/2018 4:48 AM, Peter Chen wrote:
When we are removing HCD, the xhci_configure_endpoint may be timeout.
To get rid of timeout, we'd better return before issue command.
The related log message when removing HCD like below:
[66.736633] usb 3-1: USB disconnect, device number 2
[66.737003] hub 3-1:1.0: hub_ext_port_status failed (err = -71)
[66.737054] usb 3-1.1: USB disconnect, device number 3
[66.759910] xhci-hcd xhci-hcd.1.auto: remove, state 4
[66.765043] usb usb4: USB disconnect, device number 1
[66.770169] usb 4-1: USB disconnect, device number 2
[74.008294] xhci-hcd xhci-hcd.1.auto: Timeout while waiting for
configure endpoint command
[74.018737] xhci-hcd xhci-hcd.1.auto: USB bus 4 deregistered
[74.024446] xhci-hcd xhci-hcd.1.auto: remove, state 1
[74.029594] usb usb3: USB disconnect, device number 1
[74.062310] xhci-hcd xhci-hcd.1.auto: USB bus 3 deregistered
Signed-off-by: Peter Chen
---
drivers/usb/host/xhci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 0420eefa647a..3113938063fd 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2698,7 +2698,8 @@ static int xhci_configure_endpoint(struct xhci_hcd *xhci,
spin_lock_irqsave(&xhci->lock, flags);
- if (xhci->xhc_state & XHCI_STATE_DYING) {
+ if (xhci->xhc_state & XHCI_STATE_DYING ||
+ xhci->xhc_state & XHCI_STATE_REMOVING) {
Same comment as to the patch 3/3.
spin_unlock_irqrestore(&xhci->lock, flags);
return -ESHUTDOWN;
}
MBR, Sergei
Re: Kernel memory leak on CDC-ACM device plug/unplug
2018-09-21 10:08 GMT+02:00 Oliver Neukum : > On Mi, 2018-09-19 at 16:11 +0200, Romain Izard wrote: >> While trying to debug a memory leak problem, I encountered the following >> problem: >> >> After plugging/unplugging an USB CDC-ACM device, kmemleak reports multiple >> copies of the following leak. It is not necessary to open the port for the >> leak to happen. > > Hi, > > nothing is immediately obvious to me. Could you compile a kernel with > CONFIG_DEBUG_KMEMLEAK? > The fix for this issue is the following patch: https://www.spinics.net/lists/linux-usb/msg172850.html Best regards, -- Romain Izard
Re: [PATCH] Revert "usb: typec: fusb302: Fix debugfs issue"
Hi Michael,
On Fri, Sep 21, 2018 at 11:49:23AM +0200, Michael Gebhard wrote:
> This reverts commit c9359f416207 ("usb: typec: fusb302: Fix debugfs issue")
>
> Removing debugfs directory leaves pointing at
> freed memory. The next subsequent call to fusb302_probe() causes a
> NULL pointer derenference in debugfs_create_file() in
> fusb302_debugfs_init(). This problem occurs, since is not
> only removed when unloading the driver, but also when fusb302_probe()
> fails or the link to a device is dropped.
Try this patch:
https://patchwork.kernel.org/patch/10607509/
It should fix the broblem. Let us know if it works.
Thanks,
--
heikki
[PATCH v3] arm64: dts: exynos: add OF graph between USB-PHY and MUIC
OF graph describes USB data lanes between USB-PHY and respective MUIC.
Since graph is present and DWC driver can use it to get extcon, obsolete
extcon property can be removed.
Signed-off-by: Andrzej Hajda
---
v3:
- removed #address-cells/#size-cells from ports node.
Hi Krzysztof,
This is next version of the patch I forgot. I have addressed your comments,
I hope correctly :)
Regards
Andrzej
---
.../boot/dts/exynos/exynos5433-tm2-common.dtsi| 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a1e3194b7483..95cbf5f0921d 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -868,6 +868,14 @@
};
};
};
+
+ ports {
+ port {
+ muic_to_usb: endpoint {
+ remote-endpoint =
<&usb_to_muic>;
+ };
+ };
+ };
};
regulators {
@@ -1283,12 +1291,17 @@
&usbdrd_dwc3 {
dr_mode = "otg";
- extcon = <&muic>;
};
&usbdrd30_phy {
vbus-supply = <&safeout1_reg>;
status = "okay";
+
+ port {
+ usb_to_muic: endpoint {
+ remote-endpoint = <&muic_to_usb>;
+ };
+ };
};
&xxti {
--
2.18.0
Re: [PATCH] Revert "usb: typec: fusb302: Fix debugfs issue"
> Try this patch: > https://patchwork.kernel.org/patch/10607509/ > > It should fix the broblem. Let us know if it works. It does fix the null pointers on boot. As far as i can tell, the rootdir pointer still becomes invalid after fusb302_remove(), and it should crash if fusb302_probe() is called again after remove. But I can not find a test case to trigger it. Thank you for the fix.
Re: [PATCH] Revert "usb: typec: fusb302: Fix debugfs issue"
Also, sorry for the cc messup, I'll put my two previous
mails here, just so they'll appear in the archives.
As heikki just pointed out, there already is a fix for this problem.
===
I do have a couple of questions on how to best make sure
is always NULL or pointing to a valid dentry.
Other drivers (e.g. drivers/usb/typec/tcpm.c) also seem
to handle this problem by leaving behind their debugfs rootdir.
This causes their debugfs entries to be unusable if the module
is reloaded once.
My next solution attempt would be, to check whether the rootdir
is empty, then remove it at set 'rootdir = NULL'. But attempting
to remove the rootdir everytime a link to a device is dropped seems
conceptually wrong to me since the rootdir is per driver, not per
device handled by this driver.
This leads to my third idea, the rootdir could be created and removed
in the register and unregister functions of the driver, but then
it could not use the module_i2c_driver macro to supply these functions.
Instead the modules register function would create the rootdir and then
call i2c_register_driver. However looking at other drivers using the
module_i2c_driver macro or an equivalent seems to be best practice.
===
This reverts commit c9359f416207 ("usb: typec: fusb302: Fix debugfs issue")
Removing debugfs directory leaves pointing at
freed memory. The next subsequent call to fusb302_probe() causes a
NULL pointer derenference in debugfs_create_file() in
fusb302_debugfs_init(). This problem occurs, since is not
only removed when unloading the driver, but also when fusb302_probe()
fails or the link to a device is dropped.
The original reason for the reverted commit does not apply anymore
since commit bc9832c4a192 ("USB: typec: fsusb302: no need to check
return value of debugfs_create_dir()") removed error checking on
debugfs_create_dir(). The error check caused fusb302_probe() to fail,
if the "fusb302" debugfs directory still existed from previously
loading and unloading the fusb302 module.
Signed-off-by: Michael Gebhard
---
drivers/usb/typec/fusb302/fusb302.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/typec/fusb302/fusb302.c
b/drivers/usb/typec/fusb302/fusb302.c
index 82bed9810be6..bd99bc947cb1 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -229,7 +229,6 @@ static void fusb302_debugfs_init(struct fusb302_chip *chip)
static void fusb302_debugfs_exit(struct fusb302_chip *chip)
{
debugfs_remove(chip->dentry);
- debugfs_remove(rootdir);
}
#else
--
2.19.0
Re: [PATCH v3] arm64: dts: exynos: add OF graph between USB-PHY and MUIC
On Fri, Sep 21, 2018 at 03:13:55PM +0200, Andrzej Hajda wrote: > OF graph describes USB data lanes between USB-PHY and respective MUIC. > Since graph is present and DWC driver can use it to get extcon, obsolete > extcon property can be removed. > > Signed-off-by: Andrzej Hajda > --- > v3: > - removed #address-cells/#size-cells from ports node. > > Hi Krzysztof, > > This is next version of the patch I forgot. I have addressed your comments, Thanks, applied. Best regards, Krzysztof
[PATCH -next] USB: core: remove set but not used variable 'udev'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/core/driver.c: In function 'usb_driver_claim_interface':
drivers/usb/core/driver.c:513:21: warning:
variable 'udev' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
---
drivers/usb/core/driver.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index a1f225f..5356438 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -510,7 +510,6 @@ int usb_driver_claim_interface(struct usb_driver *driver,
struct usb_interface *iface, void *priv)
{
struct device *dev;
- struct usb_device *udev;
int retval = 0;
if (!iface)
@@ -524,8 +523,6 @@ int usb_driver_claim_interface(struct usb_driver *driver,
if (!iface->authorized)
return -ENODEV;
- udev = interface_to_usbdev(iface);
-
dev->driver = &driver->drvwrap.driver;
usb_set_intfdata(iface, priv);
iface->needs_binding = 0;
[PATCH 1/5] Revert "usb: renesas_usbhs: add extcon notifier to set mode for non-otg channel"
This reverts commit 8ada211d0383b72878582bd312b984a9eae62b30.
R-Car D3 can use OTG mode in fact. So, the commit doesn't need anymore.
In other words, like other R-Car Gen3 SoCs, R-Car D3 can change the mode
by using the phy-rcar-gen3-usb2 driver.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/renesas_usbhs/common.c | 9 -
drivers/usb/renesas_usbhs/common.h | 1 -
drivers/usb/renesas_usbhs/rcar3.c | 11 ---
3 files changed, 21 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index d6c39ba..522cc09 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -677,15 +677,6 @@ static int usbhs_probe(struct platform_device *pdev)
break;
case USBHS_TYPE_RCAR_GEN3_WITH_PLL:
priv->pfunc = usbhs_rcar3_with_pll_ops;
- if (!IS_ERR_OR_NULL(priv->edev)) {
- priv->nb.notifier_call = priv->pfunc.notifier;
- ret = devm_extcon_register_notifier(&pdev->dev,
- priv->edev,
- EXTCON_USB_HOST,
- &priv->nb);
- if (ret < 0)
- dev_err(&pdev->dev, "no notifier registered\n");
- }
break;
case USBHS_TYPE_RZA1:
priv->pfunc = usbhs_rza1_ops;
diff --git a/drivers/usb/renesas_usbhs/common.h
b/drivers/usb/renesas_usbhs/common.h
index 555b3e7..3777af8 100644
--- a/drivers/usb/renesas_usbhs/common.h
+++ b/drivers/usb/renesas_usbhs/common.h
@@ -257,7 +257,6 @@ struct usbhs_priv {
struct platform_device *pdev;
struct extcon_dev *edev;
- struct notifier_block nb;
spinlock_t lock;
diff --git a/drivers/usb/renesas_usbhs/rcar3.c
b/drivers/usb/renesas_usbhs/rcar3.c
index d0ea4ff..b9a8453 100644
--- a/drivers/usb/renesas_usbhs/rcar3.c
+++ b/drivers/usb/renesas_usbhs/rcar3.c
@@ -112,16 +112,6 @@ static int usbhs_rcar3_get_id(struct platform_device *pdev)
return USBHS_GADGET;
}
-static int usbhs_rcar3_notifier(struct notifier_block *nb, unsigned long event,
- void *data)
-{
- struct usbhs_priv *priv = container_of(nb, struct usbhs_priv, nb);
-
- usbhs_rcar3_set_usbsel(priv, !!event);
-
- return NOTIFY_DONE;
-}
-
const struct renesas_usbhs_platform_callback usbhs_rcar3_ops = {
.power_ctrl = usbhs_rcar3_power_ctrl,
.get_id = usbhs_rcar3_get_id,
@@ -130,5 +120,4 @@ static int usbhs_rcar3_notifier(struct notifier_block *nb,
unsigned long event,
const struct renesas_usbhs_platform_callback usbhs_rcar3_with_pll_ops = {
.power_ctrl = usbhs_rcar3_power_and_pll_ctrl,
.get_id = usbhs_rcar3_get_id,
- .notifier = usbhs_rcar3_notifier,
};
--
1.9.1
[PATCH 5/5] usb: renesas_usbhs: add support for R-Car E3
This patch adds support for R-Car E3. This SoC needs to release
the PLL reset by the UGCTRL register like R-Car D3. So, this patch
adds a usbhs_of_match entry for this SoC with
"USBHS_TYPE_RCAR_GEN3_WITH_PLL".
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/renesas_usbhs/common.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 522cc09..a3e1290 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -560,6 +560,10 @@ static int usbhsc_drvcllbck_notify_hotplug(struct
platform_device *pdev)
.data = (void *)USBHS_TYPE_RCAR_GEN3,
},
{
+ .compatible = "renesas,usbhs-r8a77990",
+ .data = (void *)USBHS_TYPE_RCAR_GEN3_WITH_PLL,
+ },
+ {
.compatible = "renesas,usbhs-r8a77995",
.data = (void *)USBHS_TYPE_RCAR_GEN3_WITH_PLL,
},
--
1.9.1
[PATCH 2/5] Revert "usb: renesas_usbhs: set the mode by using extcon state for non-otg channel"
This reverts commit cd14247d5c14b9b20bb3d3dfcaa899ca22c8dccc.
R-Car D3 can use OTG mode in fact. So, the commit doesn't need anymore.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/renesas_usbhs/rcar3.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/rcar3.c
b/drivers/usb/renesas_usbhs/rcar3.c
index b9a8453..50e5fb5 100644
--- a/drivers/usb/renesas_usbhs/rcar3.c
+++ b/drivers/usb/renesas_usbhs/rcar3.c
@@ -27,7 +27,6 @@
* Remarks: bit[31:11] and bit[9:6] should be 0
*/
#define UGCTRL2_RESERVED_3 0x0001 /* bit[3:0] should be B'0001 */
-#define UGCTRL2_USB0SEL_EHCI 0x0010
#define UGCTRL2_USB0SEL_HSUSB 0x0020
#define UGCTRL2_USB0SEL_OTG0x0030
#define UGCTRL2_VBUSSEL0x0400
@@ -50,14 +49,6 @@ static void usbhs_rcar3_set_ugctrl2(struct usbhs_priv *priv,
u32 val)
usbhs_write32(priv, UGCTRL2, val | UGCTRL2_RESERVED_3);
}
-static void usbhs_rcar3_set_usbsel(struct usbhs_priv *priv, bool ehci)
-{
- if (ehci)
- usbhs_rcar3_set_ugctrl2(priv, UGCTRL2_USB0SEL_EHCI);
- else
- usbhs_rcar3_set_ugctrl2(priv, UGCTRL2_USB0SEL_HSUSB);
-}
-
static int usbhs_rcar3_power_ctrl(struct platform_device *pdev,
void __iomem *base, int enable)
{
@@ -83,14 +74,10 @@ static int usbhs_rcar3_power_and_pll_ctrl(struct
platform_device *pdev,
struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
u32 val;
int timeout = 1000;
- bool is_host = false;
if (enable) {
usbhs_write32(priv, UGCTRL, 0); /* release PLLRESET */
- if (priv->edev)
- is_host = extcon_get_state(priv->edev, EXTCON_USB_HOST);
-
- usbhs_rcar3_set_usbsel(priv, is_host);
+ usbhs_rcar3_set_ugctrl2(priv, UGCTRL2_USB0SEL_HSUSB);
usbhs_bset(priv, LPSTS, LPSTS_SUSPM, LPSTS_SUSPM);
do {
--
1.9.1
[PATCH 4/5] dt-bindings: usb: renesas_usbhs: add bindings for r8a77990
This patch adds bindings for r8a77990 (R-Car E3). Signed-off-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index 15fb3b3..a649329 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -14,6 +14,7 @@ Required properties: - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device - "renesas,usbhs-r8a77965" for r8a77965 (R-Car M3-N) compatible device + - "renesas,usbhs-r8a77990" for r8a77990 (R-Car E3) compatible device - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device - "renesas,usbhs-r7s72100" for r7s72100 (RZ/A1) compatible device - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices -- 1.9.1
[PATCH 3/5] usb: renesas_usbhs: rcar3: Use OTG mode for R-Car D3
Since R-Car D3 can use OTG mode, this patch changes the UGCTRL2
value to UGCTRL2_USB0SEL_OTG and UGCTRL2_VBUSSEL like other R-Car
Gen3 SoCs.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/renesas_usbhs/rcar3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/renesas_usbhs/rcar3.c
b/drivers/usb/renesas_usbhs/rcar3.c
index 50e5fb5..aa38204 100644
--- a/drivers/usb/renesas_usbhs/rcar3.c
+++ b/drivers/usb/renesas_usbhs/rcar3.c
@@ -77,7 +77,8 @@ static int usbhs_rcar3_power_and_pll_ctrl(struct
platform_device *pdev,
if (enable) {
usbhs_write32(priv, UGCTRL, 0); /* release PLLRESET */
- usbhs_rcar3_set_ugctrl2(priv, UGCTRL2_USB0SEL_HSUSB);
+ usbhs_rcar3_set_ugctrl2(priv,
+ UGCTRL2_USB0SEL_OTG | UGCTRL2_VBUSSEL);
usbhs_bset(priv, LPSTS, LPSTS_SUSPM, LPSTS_SUSPM);
do {
--
1.9.1
[PATCH 0/5] usb: renesas_usbhs: use otg mode and add support for R-Car E3
This patch set is based on the latest Greg's usb.git / usb-testing branch (the commit id is ae8a2ca8a2215c7e31e6d874f7303801bb15fbbc) The previous code set the mode as peripheral mode by the UGCTRL2 register for R-Car D3. But, this SoC can select OTG mode in fact. So, at first, I'd like to revert related patches I submitted in patch 1 and 2. Then, in patch 3, it sets the mode as "OTG" and in patch 4 and 5, it supports for R-Car E3. To use this controller for R-Car D3 and E3, we need the following patch set. Otherwize, the mode will not be changed to peripheral mode by the phy's COMMCTRL register: https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=21629 Yoshihiro Shimoda (5): Revert "usb: renesas_usbhs: add extcon notifier to set mode for non-otg channel" Revert "usb: renesas_usbhs: set the mode by using extcon state for non-otg channel" usb: renesas_usbhs: rcar3: Use OTG mode for R-Car D3 dt-bindings: usb: renesas_usbhs: add bindings for r8a77990 usb: renesas_usbhs: add support for R-Car E3 .../devicetree/bindings/usb/renesas_usbhs.txt | 1 + drivers/usb/renesas_usbhs/common.c | 13 --- drivers/usb/renesas_usbhs/common.h | 1 - drivers/usb/renesas_usbhs/rcar3.c | 27 ++ 4 files changed, 7 insertions(+), 35 deletions(-) -- 1.9.1
[PATCH] xhci: Add check for invalid byte size error when UAS devices are connected.
From: Sandeep Singh Observed "TRB completion code (27)" error which corresponds to Stopped - Length Invalid error(xhci spec section 4.17.4) while connecting USB to SATA bridge. Looks like this case was not considered when the following patch[1] was committed. Hence adding this new check which can prevent the invalid byte size error. [1] ade2e3a xhci: handle transfer events without TRB pointer Signed-off-by: Sandeep Singh cc: Nehal Shah cc: Shyam Sundar S K --- drivers/usb/host/xhci-ring.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index f0a99aa..8ba2cbc 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2246,6 +2246,7 @@ static int handle_tx_event(struct xhci_hcd *xhci, goto cleanup; case COMP_RING_UNDERRUN: case COMP_RING_OVERRUN: + case COMP_STOPPED_LENGTH_INVALID: goto cleanup; default: xhci_err(xhci, "ERROR Transfer event for unknown stream ring slot %u ep %u\n", -- 2.7.4
Re: [PATCH] usb: cdc_acm: Do not leak URB buffers
On Do, 2018-09-20 at 16:49 +0200, Romain Izard wrote: > When the ACM TTY port is disconnected, the URBs it uses must be killed, and > then the buffers must be freed. Unfortunately a previous refactor removed > the code freeing the buffers because it looked extremely similar to the > code killing the URBs. > > As a result, there were many new leaks for each plug/unplug cycle of a > CDC-ACM device, that were detected by kmemleak. > > Restore the missing code, and the memory leak is removed. Try as i may, I don't see the difference. Could you put a comment exactly describing the issue into the code itself, lest this problem reappear? Regards Oliver
Re: [PATCH v5 0/8] usb: dwc3: Fix broken BULK stream support to dwc3 gadget driver
Hello Anurag, On 9/15/2018 8:00 PM, Anurag Kumar Vulisha wrote: > These patch series fixes the broken BULK streaming support in > dwc3 gadget driver. > > Changes in v5: > 1. Removed the dev_dbg prints as suggested bt "Thinh Nguyen" > > Changes in v4: > 1. Corrected the commit messgae and stream timeout description > as suggested by "Thinh Nguyen" > > Changes in v3: > 1. Added the changes suggested by "Thinh Nguyen" > > Changes in v2: > 1. Added "usb: dwc3:" in subject heading > > Anurag Kumar Vulisha (8): > usb: dwc3: Correct the logic for checking TRB full in > __dwc3_prepare_one_trb() > usb: dwc3: update stream id in depcmd > usb: dwc3: make controller clear transfer resources after complete > usb: dwc3: implement stream transfer timeout > usb: dwc3: don't issue no-op trb for stream capable endpoints > usb: dwc3: check for requests in started list for stream capable > endpoints > usb: dwc3: Check for IOC/LST bit in both event->status and TRB->ctrl > fields > usb: dwc3: Check MISSED ISOC bit only for ISOC endpoints > > drivers/usb/dwc3/core.h | 7 > drivers/usb/dwc3/gadget.c | 85 > ++- > 2 files changed, 84 insertions(+), 8 deletions(-) > Tested-By: Tejas Joglekar I have tested this patch series except the stream transfer timeout patch on HAPS-DX platform. I am not aware of exact scenarios to test the timeout patch and don't have a test for the same. Thanks, Tejas Joglekar
RE: [PATCH v5 0/8] usb: dwc3: Fix broken BULK stream support to dwc3 gadget driver
Hi Tejas, >-Original Message- >From: Tejas Joglekar [mailto:tejas.jogle...@synopsys.com] >Sent: Friday, September 21, 2018 7:01 PM >To: Anurag Kumar Vulisha ; ba...@kernel.org; >gre...@linuxfoundation.org >Cc: v.anuragku...@gmail.com; linux-usb@vger.kernel.org; linux- >ker...@vger.kernel.org; thinh.ngu...@synopsys.com; Ajay Yugalkishore Pandey >; joglekarte...@gmail.com >Subject: Re: [PATCH v5 0/8] usb: dwc3: Fix broken BULK stream support to dwc3 >gadget driver > >Hello Anurag, >On 9/15/2018 8:00 PM, Anurag Kumar Vulisha wrote: >> These patch series fixes the broken BULK streaming support in >> dwc3 gadget driver. >> >> Changes in v5: >> 1. Removed the dev_dbg prints as suggested bt "Thinh Nguyen" >> >> Changes in v4: >> 1. Corrected the commit messgae and stream timeout description >> as suggested by "Thinh Nguyen" >> >> Changes in v3: >> 1. Added the changes suggested by "Thinh Nguyen" >> >> Changes in v2: >> 1. Added "usb: dwc3:" in subject heading >> >> Anurag Kumar Vulisha (8): >> usb: dwc3: Correct the logic for checking TRB full in >> __dwc3_prepare_one_trb() >> usb: dwc3: update stream id in depcmd >> usb: dwc3: make controller clear transfer resources after complete >> usb: dwc3: implement stream transfer timeout >> usb: dwc3: don't issue no-op trb for stream capable endpoints >> usb: dwc3: check for requests in started list for stream capable >> endpoints >> usb: dwc3: Check for IOC/LST bit in both event->status and TRB->ctrl >> fields >> usb: dwc3: Check MISSED ISOC bit only for ISOC endpoints >> >> drivers/usb/dwc3/core.h | 7 >> drivers/usb/dwc3/gadget.c | 85 >++- >> 2 files changed, 84 insertions(+), 8 deletions(-) >> >Tested-By: Tejas Joglekar >I have tested this patch series except the stream transfer timeout patch on >HAPS-DX >platform. I am not aware of exact scenarios to test the timeout patch and >don't have >a test for the same. Thanks for testing the patches. The issue mentioned in the timeout patch (Patch 4) will occur very rarely on the long runs and only when tested with stream capable host. This issue happens only when the host & dwc3 controller go out of sync, where the dwc3 controller may wait for host to issue prime transaction and host may wait for the gadget to issue ERDY. I used controller version 2.90A for testing this issue. This issue is mentioned in databook section 9.5.2 Thanks, Anurag Kumar Vulisha
[PATCH] usb: typec: tcpm: Fix APDO PPS order checking to be based on voltage
Current code mistakenly checks against max current to determine
order but this should be max voltage. This commit fixes the issue
so order is correctly determined, thus avoiding failure based on
a higher voltage PPS APDO having a lower maximum current output,
which is actually valid.
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS")
Cc:
Signed-off-by: Adam Thomson
---
Code based on usb-testing branch (ae8a2ca8a2215c7e31e6d874f7303801bb15fbb)
drivers/usb/typec/tcpm/tcpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 4f1f421..c11b3be 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -1430,8 +1430,8 @@ static enum pdo_err tcpm_caps_err(struct tcpm_port *port,
const u32 *pdo,
if (pdo_apdo_type(pdo[i]) != APDO_TYPE_PPS)
break;
- if (pdo_pps_apdo_max_current(pdo[i]) <
- pdo_pps_apdo_max_current(pdo[i - 1]))
+ if (pdo_pps_apdo_max_voltage(pdo[i]) <
+ pdo_pps_apdo_max_voltage(pdo[i - 1]))
return PDO_ERR_PPS_APDO_NOT_SORTED;
else if (pdo_pps_apdo_min_voltage(pdo[i]) ==
pdo_pps_apdo_min_voltage(pdo[i - 1])
&&
--
1.9.1
Re: [PATCH] usb: typec: tcpm: Fix APDO PPS order checking to be based on voltage
On Fri, Sep 21, 2018 at 04:04:11PM +0100, Adam Thomson wrote:
> Current code mistakenly checks against max current to determine
> order but this should be max voltage. This commit fixes the issue
> so order is correctly determined, thus avoiding failure based on
> a higher voltage PPS APDO having a lower maximum current output,
> which is actually valid.
>
> Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS")
> Cc:
> Signed-off-by: Adam Thomson
Makes sense.
Reviewed-by: Guenter Roeck
> ---
> Code based on usb-testing branch (ae8a2ca8a2215c7e31e6d874f7303801bb15fbb)
>
> drivers/usb/typec/tcpm/tcpm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 4f1f421..c11b3be 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -1430,8 +1430,8 @@ static enum pdo_err tcpm_caps_err(struct tcpm_port
> *port, const u32 *pdo,
> if (pdo_apdo_type(pdo[i]) != APDO_TYPE_PPS)
> break;
>
> - if (pdo_pps_apdo_max_current(pdo[i]) <
> - pdo_pps_apdo_max_current(pdo[i - 1]))
> + if (pdo_pps_apdo_max_voltage(pdo[i]) <
> + pdo_pps_apdo_max_voltage(pdo[i - 1]))
> return PDO_ERR_PPS_APDO_NOT_SORTED;
> else if (pdo_pps_apdo_min_voltage(pdo[i]) ==
> pdo_pps_apdo_min_voltage(pdo[i - 1])
> &&
> --
> 1.9.1
>
