Re: [PATCH 0/3] Fix OMAP EHCI probe & assorted cleanups
Hi Tony, On Tuesday, 11 September 2018 19:25:38 EEST Tony Lindgren wrote: > * Laurent Pinchart [180911 16:12]: > > On Tuesday, 11 September 2018 18:16:41 EEST Tony Lindgren wrote: > >> * Laurent Pinchart [180911 15:10]: > >>> Hello, > >>> > >>> This series fixes a v4.19-rc1 regression that results in OMAP EHCI > >>> failing to probe (patch 1/3) and then moves on to cleaning up related > >>> code (patches 2/3 and 3/3). > >>> > >>> The first patch is a regression fix and should thus be merged before > >>> v4.19. The other two patches can wait until v4.20. > >> > >> Hmm can you please check again with this patch applied: > >> > >> "[PATCH] mfd: omap-usb-host: Fix dts probe of children" > > > > This fixes the issue for me. > > > > Tested-by: Laurent Pinchart > > OK good to hear. The fix is still not in v4.19-rc4 :-S Could you make sure it doesn't miss v4.19 ? > >> That was supposed to be queued for v4.18 but fell through the > >> cracks and I only recently noticed it but Lee has it tagged > >> now for v4.19-rc series. > >> > >> But maybe there are additional issues.. > > > > I think we can go one step further and avoid using fs_initcall, but that > > can wait for v4.20. What's your opinion on that ? If you agree I'll > > resubmit this series rebased on top of the aforementioned patch. > > Yes sounds good to me. Actually with ti-sysc we're probing the > interconnect target modules at module_init time, so any children > will only get probed after that and the fs_initcall is not > doing anything before that mhuwhhaa. > > But yeah hopefully the fs_initcall is no longer needed with > device tree based booting even before we have all the dts > files using ti-sysc. > > >>> Tony, as patch 1/3 fixes a problem introduced by one of your DT > >>> changes, > >>> could you please review it ? Out of curiosity, is ethernet on the > >>> Pandaboard not part of your regression tests ? > >> > >> Sorry not any longer.. I've switched over to wlan based > >> setup for PM testing: > >> > >> 1. u-boot downloads kernel dtb and modules.tar.gz and writes > >>modules.tar.gz to MMC card > >> > >> 2. on kernel boot, first modules.tar.gz is unpacked > >> > >> 3. distro brings up wlan but no USB ether > >> > >> So I can now test also PM on pandaboard-es. I do have ohci > >> enabled on droid4 though for mdm6600 modem, but usually have > >> ehci disabled as the w3glte modem on ehci does not yet work > >> with mainline kernel. > > > > :-/ If you have a test script that analyzes the kernel log, it would be > > useful to add a check to verify that the USB ethernet interface chip is > > detected. That would prevent the regression we're seeing here. > > Yeah sorry about the regression. > > Hrm well it goes back to the droid4 lcd patches again that I've > been carrying along :) I did not notice this was still pending > too buried into the pile I was carrying until recently.. The > original fix was already sent back in April. > > I in fact worked all summer using Linux next (working) snapshots > on droid4 with a lapdock over ssh and mdm6600 modem on it's ohci > bus being my main connection. So the *hci is getting tested by > real use in this case, no need to analyze kernel logs unless > something goes wrong. -- Regards, Laurent Pinchart
Re: [PATCH 0/3] Fix OMAP EHCI probe & assorted cleanups
On Sun, 23 Sep 2018, Laurent Pinchart wrote: > Hi Tony, > > On Tuesday, 11 September 2018 19:25:38 EEST Tony Lindgren wrote: > > * Laurent Pinchart [180911 16:12]: > > > On Tuesday, 11 September 2018 18:16:41 EEST Tony Lindgren wrote: > > >> * Laurent Pinchart [180911 15:10]: > > >>> Hello, > > >>> > > >>> This series fixes a v4.19-rc1 regression that results in OMAP EHCI > > >>> failing to probe (patch 1/3) and then moves on to cleaning up related > > >>> code (patches 2/3 and 3/3). > > >>> > > >>> The first patch is a regression fix and should thus be merged before > > >>> v4.19. The other two patches can wait until v4.20. > > >> > > >> Hmm can you please check again with this patch applied: > > >> > > >> "[PATCH] mfd: omap-usb-host: Fix dts probe of children" > > > > > > This fixes the issue for me. > > > > > > Tested-by: Laurent Pinchart > > > > OK good to hear. > > The fix is still not in v4.19-rc4 :-S Could you make sure it doesn't miss > v4.19 ? I'm going to send these today: mfd: omap-usb-host: Fix dts probe of children mfd: da9063: Fix DT probing with constraints -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 0/3] Fix OMAP EHCI probe & assorted cleanups
On Sun, 23 Sep 2018, Lee Jones wrote: > On Sun, 23 Sep 2018, Laurent Pinchart wrote: > > > Hi Tony, > > > > On Tuesday, 11 September 2018 19:25:38 EEST Tony Lindgren wrote: > > > * Laurent Pinchart [180911 16:12]: > > > > On Tuesday, 11 September 2018 18:16:41 EEST Tony Lindgren wrote: > > > >> * Laurent Pinchart [180911 15:10]: > > > >>> Hello, > > > >>> > > > >>> This series fixes a v4.19-rc1 regression that results in OMAP EHCI > > > >>> failing to probe (patch 1/3) and then moves on to cleaning up related > > > >>> code (patches 2/3 and 3/3). > > > >>> > > > >>> The first patch is a regression fix and should thus be merged before > > > >>> v4.19. The other two patches can wait until v4.20. > > > >> > > > >> Hmm can you please check again with this patch applied: > > > >> > > > >> "[PATCH] mfd: omap-usb-host: Fix dts probe of children" > > > > > > > > This fixes the issue for me. > > > > > > > > Tested-by: Laurent Pinchart > > > > > > OK good to hear. > > > > The fix is still not in v4.19-rc4 :-S Could you make sure it doesn't miss > > v4.19 ? > > I'm going to send these today: > > mfd: omap-usb-host: Fix dts probe of children > mfd: da9063: Fix DT probing with constraints Greg just pulled. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
High power use ITE Tech 8350 - bug?
Hi, I have the aforementioned gyroscope sensor device handled by the usbhid driver. I find that it uses a considerable amount of power (relatively). When I look in powertop it shows a 40% use after a cold boot, and after I awake from suspend-to-ram, it shows 100% usage at around 700mw. That's roughly a tenth of the typical battery drain on my laptop. Is there any way I can try and diagnose this and 1. Find out what the typical power use should be? 2. How I can fix the 100% stuck power-usage on resume-from-suspend? I'm on kernel 4.14.65. Thanks! Luciano Bus 001 Device 003: ID 048d:8350 Integrated Technology Express, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x048d Integrated Technology Express, Inc. idProduct 0x8350 bcdDevice 10.17 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.12 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength2532 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1
Re: [BUG] usb: USB Mass Storage - USB cable is bad warning
On Sat, 22 Sep 2018, Barry Grussling wrote:
> When I plug my USB reader (11b0:6348) into my computer (MSI X399
> Carbon Pro, Threadripper 1900X),
> I get warnings about a bad usb cable:
> Sep 22 11:11:51 ciri kernel: usb 5-3.3-port4: Cannot enable. Maybe the
> USB cable is bad?
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: new high-speed USB device
> number 15 using xhci_hcd
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: New USB device found,
> idVendor=11b0, idProduct=6348, bcdDevice= 1.11
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: New USB device strings:
> Mfr=1, Product=2, SerialNumber=3
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: Product: USB3.0 Media Reader
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: Manufacturer: Kingston
> Sep 22 11:11:52 ciri kernel: usb 5-3.3.4: SerialNumber: 201402131335
> Sep 22 11:11:52 ciri kernel: usb-storage 5-3.3.4:1.0: USB Mass Storage
> device detected
> Sep 22 11:11:52 ciri kernel: scsi host11: usb-storage 5-3.3.4:1.0
>
> This warning shows up on all USB3 ports that I plug it in to (tried 3
> of them directly off the MB).
> I have also tried it using on the other side of a USB3 hub (2109:8110)
> and still receive the
> same message. I have tried 3 different USB cables and all report the
> same warning.
>
> If I instead plug into one of the USB2 only ports ("console ports" on
> MB) I get no warning:
> Sep 22 11:37:15 ciri kernel: usb 1-12: new high-speed USB device
> number 8 using xhci_hcd
> Sep 22 11:37:15 ciri kernel: usb 1-12: New USB device found,
> idVendor=11b0, idProduct=6348, bcdDevice= 1.11
> Sep 22 11:37:15 ciri kernel: usb 1-12: New USB device strings: Mfr=1,
> Product=2, SerialNumber=3
> Sep 22 11:37:15 ciri kernel: usb 1-12: Product: USB3.0 Media Reader
> Sep 22 11:37:15 ciri kernel: usb 1-12: Manufacturer: Kingston
> Sep 22 11:37:15 ciri kernel: usb 1-12: SerialNumber: 201402131335
> Sep 22 11:37:15 ciri kernel: usb-storage 1-12:1.0: USB Mass Storage
> device detected
> Sep 22 11:37:15 ciri kernel: scsi host11: usb-storage 1-12:1.0
>
> The warning appears to be mostly benign, as functionality appears to
> be unaffected. It did
> result in me purchasing a few replacement USB cables in an attempt to
> remove the warning.
>
> Anything I can do to "fix" this? I have verified the USB reader
> (FCR-HS3) is running the latest
> firmware from Kingston.
>
> I am running Linux v4.19-rc4-89-g6ad49fa1993d.
There's no easy way to tell what the cause is, but you can get a little
more information by collecting a usbmon trace while plugging in the
media reader.
Alan Stern
Re: [PATCH 0/3] Fix OMAP EHCI probe & assorted cleanups
Hi Lee, On Sunday, 23 September 2018 18:38:28 EEST Lee Jones wrote: > On Sun, 23 Sep 2018, Lee Jones wrote: > > On Sun, 23 Sep 2018, Laurent Pinchart wrote: > >> On Tuesday, 11 September 2018 19:25:38 EEST Tony Lindgren wrote: > >>> * Laurent Pinchart [180911 16:12]: > On Tuesday, 11 September 2018 18:16:41 EEST Tony Lindgren wrote: > > * Laurent Pinchart [180911 15:10]: > >> Hello, > >> > >> This series fixes a v4.19-rc1 regression that results in OMAP EHCI > >> failing to probe (patch 1/3) and then moves on to cleaning up > >> related code (patches 2/3 and 3/3). > >> > >> The first patch is a regression fix and should thus be merged > >> before v4.19. The other two patches can wait until v4.20. > > > > Hmm can you please check again with this patch applied: > > > > "[PATCH] mfd: omap-usb-host: Fix dts probe of children" > > This fixes the issue for me. > >>> > Tested-by: Laurent Pinchart > >>> > >>> OK good to hear. > >> > >> The fix is still not in v4.19-rc4 :-S Could you make sure it doesn't > >> miss v4.19 ? > > > > I'm going to send these today: > > mfd: omap-usb-host: Fix dts probe of children > > mfd: da9063: Fix DT probing with constraints > > Greg just pulled. Thank you, much appreciated. -- Regards, Laurent Pinchart
[PATCH v5] USB: serial: ftdi_sio: implement GPIO support for FT-X devices
This patch allows using the CBUS pins of FT-X devices as GPIO in CBUS
bitbanging mode. There is no conflict between the GPIO and VCP
functionality in this mode. Tested on FT230X and FT231X.
As there is no way to request the current CBUS register configuration
from the device, all CBUS pins are set to a known state when the first
GPIO is requested. This allows using libftdi to set the GPIO pins
before loading this module for UART functionality, a behavior that
existing applications might be relying upon (though no specific case
is known to the authors of this patch).
Signed-off-by: Karoly Pados
---
Changelog:
- v2: Fix compile error when CONFIG_GPIOLIB is not defined.
- v3: Incorporate review feedback.
- v4: Include linux/gpio/driver.h unconditionally.
Replace and invert gpio_input with gpio_output.
Make ftdi_gpio_direction_get return 0/1.
Change dev_err msg in ftdi_set_bitmode_req.
Change formatting of error checking in ftdi_gpio_get.
Drop dev_err in ftdi_gpio_set.
Remove some line breaks and empty lines.
Change error handling in ftdi_read_eeprom (and adjust caller).
Replace SIO->FTX in FTDI_SIO_CBUS_MUX_GPIO macro name.
- v5: Read only 4 bytes from eeprom in ftx_gpioconf_init.
Compare ftdi_read_eeprom result with 0 instead of eq. cehck.
Reserve 4 GPIOs even for FT234X.
Release CBUS after gpiochip deregister to avoid possible race.
Adjust comment on FTDI_SIO_SET_BITMODE macro.
Protect GPIO value/dir setting with mutex.
Add support for gpiochip.get_multiple and set_multiple.
Add names to GPIO lines.
Of special note, in this vesion of the patch GPIO names and support for
get_multiple / set_multiple methods have been added in addition to earlier
review comments.
Though there is no code copied, libftdi was used as
a reference. ftdi_read_eeprom is based on Loic Poulain's patch.
This patch uses CBUS bitbanging mode, which works nicely in parallel with
the VCP function. The other modes do not, and so IMHO it does not make
sense to try adding them to this same module.
For this device, whenever changing the state of any single pin, all the
others need to be written too. This means in order to change any pin, we
need to know the current state of all the others. So when using GPIO,
we need to have a known starting state for all pins, but there seems to
be no way to retrieve the existing GPIO configuration (directions and
output register values). The way I handle this in this patch is that when
requesting a GPIO for the first time, the module initializes all pins to
a known default state (to inputs). Input was chosen, because a potentially
floating pin is better than a potential driver conflict, because the latter
could result in hardware damage. However, if the user does not request a
GPIO, the CBUS pins are not initialized, avoiding unnecessarily changing
hardware state. I figured I cannot rely on the default power-on state of
the device for this as the user might have used libftdi before loading
our module. When the module is unloaded, CBUS bitbanging mode is exited
if it were us who entered it earlier.
drivers/usb/serial/ftdi_sio.c | 297 +-
drivers/usb/serial/ftdi_sio.h | 27 +++-
2 files changed, 322 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index b5cef322826f..749654a6a902 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "ftdi_sio.h"
#include "ftdi_sio_ids.h"
@@ -72,6 +73,14 @@ struct ftdi_private {
unsigned int latency; /* latency setting in use */
unsigned short max_packet_size;
struct mutex cfg_lock; /* Avoid mess by parallel calls of config
ioctl() and change_speed() */
+#if defined(CONFIG_GPIOLIB)
+ struct gpio_chip gc;
+ boolgpio_registered; /* is the gpiochip in kernel registered */
+ boolgpio_used;/* true if the user requested a gpio */
+ u8 gpio_altfunc; /* which pins are in gpio mode */
+ u8 gpio_output; /* pin directions cache */
+ u8 gpio_value; /* pin value for outputs */
+#endif
};
/* struct ftdi_sio_quirk is used by devices requiring special attention. */
@@ -1766,6 +1775,282 @@ static void remove_sysfs_attrs(struct usb_serial_port
*port)
}
+#if defined(CONFIG_GPIOLIB)
+
+static int ftdi_set_bitmode_req(struct usb_serial_port *port, u8 mode)
+{
+ struct ftdi_private *priv = usb_get_serial_port_data(port);
+ struct usb_serial *serial = port->serial;
+ int result;
+ u16 val;
+
+ val = (mode << 8) | (priv->gpio_output << 4) | priv->gpio_value;
+ result = usb_control_msg(serial->dev,
+usb_sndctrlpipe(serial->dev, 0),
+FTDI_SIO_SET_BITMODE_REQUEST,
+
Re: general protection fault in usb_find_alt_setting
On Sun, Sep 23, 2018 at 11:11 AM, Vladis Dronov wrote: > #syz fix: USB: handle NULL config in usb_find_alt_setting() > #syz dup: general protection fault in usb_find_alt_setting (2) Same here. syzbot process designed in such way that it will not open second version of the bug (2) for the same bug. syzbot waits until the fixing commit reaches all tested tree and only then closes a bug. If the crash is spotted again _after_ that, then syzbot creates second version of the bug (2). But at that point it has to be a different bug requiring a different fix. So this should not be a dup, and should not fixed with the same commit as the first version.
Re: general protection fault in usb_find_alt_setting
Hello, Dmitry, Thank you for the reply. I probably do not properly understand how syzcaller works then. Can you please, have a look at my reasoning. The bug: https://syzkaller.appspot.com/bug?id=4b88ff5aa6aa88f9283a45cc62f16e55b0722131 (Reported-by: syzbot+c99ecc8a2c68eb7e06cf2f652e60d63d6fbe2...@syzkaller.appspotmail.com, "[upstream] general protection fault in usb_find_alt_setting") was not fixed. it was closed as invalid, so, afaiu, all the work has stopped for it. So syzbot did not wait until the fixing commit reached all tested trees, and the crash was not spotted again _after_ that. Then I look at the bug: https://syzkaller.appspot.com/bug?id=a0ec6260a1d37288a4508250fe30a5604ceec666 (Reported-by: syzbot+19c3aaef85a89d451...@syzkaller.appspotmail.com, "[upstream] general protection fault in usb_find_alt_setting (2)") And I see the crash happens at the same place _and_ at the same code: (bug id=a0ec6260a1d3) RIP: 0010:usb_find_alt_setting+0x38/0x310 drivers/usb/core/usb.c:231 Code: ... fd 48 8d 7b 04 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 86 02 00 00 (bug id=4b88ff5aa6aa) Code: ... fd 48 8d 7b 04 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 a1 02 00 RIP: usb_find_alt_setting+0x38/0x310 drivers/usb/core/usb.c:231 RSP: 88005893f610 This makes me be sure these are the same bug (dup) which are fixed by the same commit "USB: handle NULL config in usb_find_alt_setting()". As I'm kinda a perfectionist, I would like to mark (bug id=4b88ff5aa6aa) as fixed by this commit and not closed as invalid. Best regards, Vladis Dronov | Red Hat, Inc. | Product Security Engineer - Original Message - > From: "Dmitry Vyukov" > To: "Vladis Dronov" > Cc: "syzbot" > , > "syzkaller-bugs" > , "Greg Kroah-Hartman" > , "Johan Hovold" > , "kai heng feng" , "LKML" > , "USB list" > > Sent: Sunday, September 23, 2018 6:27:24 PM > Subject: Re: general protection fault in usb_find_alt_setting > > On Sun, Sep 23, 2018 at 11:11 AM, Vladis Dronov wrote: > > #syz fix: USB: handle NULL config in usb_find_alt_setting() > > #syz dup: general protection fault in usb_find_alt_setting (2) > > Same here. > syzbot process designed in such way that it will not open second > version of the bug (2) for the same bug. syzbot waits until the fixing > commit reaches all tested tree and only then closes a bug. If the > crash is spotted again _after_ that, then syzbot creates second > version of the bug (2). But at that point it has to be a different bug > requiring a different fix. > So this should not be a dup, and should not fixed with the same commit > as the first version.
[PATCH] USB: serial: cypress_m8: fix spelling mistake "retreiving" -> "retrieving"
From: Colin Ian King
Trivial fix to spelling mistake in dev_dbg message
Signed-off-by: Colin Ian King
---
drivers/usb/serial/cypress_m8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/cypress_m8.c b/drivers/usb/serial/cypress_m8.c
index e0035c023120..31c6091be46a 100644
--- a/drivers/usb/serial/cypress_m8.c
+++ b/drivers/usb/serial/cypress_m8.c
@@ -378,7 +378,7 @@ static int cypress_serial_control(struct tty_struct *tty,
retval = -ENOTTY;
goto out;
}
- dev_dbg(dev, "%s - retreiving serial line settings\n",
__func__);
+ dev_dbg(dev, "%s - retrieving serial line settings\n",
__func__);
do {
retval = usb_control_msg(port->serial->dev,
usb_rcvctrlpipe(port->serial->dev, 0),
--
2.17.1
[PATCH] usb: dwc2: remove set but unused variable
This patch removes a set but unused variable in hcd.c. Fixes gcc warning: variable ‘data_fifo’ set but not used [-Wunused-but-set-variable] Signed-off-by: Joshua Abraham --- drivers/usb/dwc2/hcd.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index 2bd6e6bfc241..5f23b933cafc 100644 --- a/drivers/usb/dwc2/hcd.c +++ b/drivers/usb/dwc2/hcd.c @@ -1328,14 +1328,11 @@ static void dwc2_hc_write_packet(struct dwc2_hsotg *hsotg, u32 remaining_count; u32 byte_count; u32 dword_count; - u32 __iomem *data_fifo; u32 *data_buf = (u32 *)chan->xfer_buf; if (dbg_hc(chan)) dev_vdbg(hsotg->dev, "%s()\n", __func__); - data_fifo = (u32 __iomem *)(hsotg->regs + HCFIFO(chan->hc_num)); - remaining_count = chan->xfer_len - chan->xfer_count; if (remaining_count > chan->max_packet) byte_count = chan->max_packet; -- 2.17.1
Re: [PATCH v5 0/8] usb: dwc3: Fix broken BULK stream support to dwc3 gadget driver
Hello Anurag, On 9/21/2018 7:36 PM, Anurag Kumar Vulisha wrote: > 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 > > I see, as it is rare so maybe it is not seen here. I have used 3.30A for testing. I will keep watch on this issue during my tests. --- Thanks, Tejas Joglekar
Re: [PATCH] usb: dwc2: remove set but unused variable
On 9/24/2018 5:41 AM, Josh Abraham wrote: > This patch removes a set but unused variable in hcd.c. > > Fixes gcc warning: > variable ‘data_fifo’ set but not used [-Wunused-but-set-variable] > > Signed-off-by: Joshua Abraham > --- > drivers/usb/dwc2/hcd.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c > index 2bd6e6bfc241..5f23b933cafc 100644 > --- a/drivers/usb/dwc2/hcd.c > +++ b/drivers/usb/dwc2/hcd.c > @@ -1328,14 +1328,11 @@ static void dwc2_hc_write_packet(struct dwc2_hsotg > *hsotg, > u32 remaining_count; > u32 byte_count; > u32 dword_count; > - u32 __iomem *data_fifo; > u32 *data_buf = (u32 *)chan->xfer_buf; > > if (dbg_hc(chan)) > dev_vdbg(hsotg->dev, "%s()\n", __func__); > > - data_fifo = (u32 __iomem *)(hsotg->regs + HCFIFO(chan->hc_num)); > - > remaining_count = chan->xfer_len - chan->xfer_count; > if (remaining_count > chan->max_packet) > byte_count = chan->max_packet; > Acked-by: Minas Harutyunyan
Re: [PATCH] usb: dwc2: Fix HiKey regression caused by power_down feature
Hi John, On 9/21/2018 05:05, John Stultz wrote: > On Thu, Sep 20, 2018 at 7:17 AM, Artur Petrosyan > wrote: >> On 5/23/2018 01:57, John Stultz wrote: >>> Its done automatically, when the OTG cable is detected it the host >>> ports are disabled and when the OTG port is empty the host ports are >>> enabled. >>> >>> Let me know if you need anything else! >>> >> >> Please apply the patch set with this cover letter "[PATCH 0/3] usb: >> dwc2: Fix hibernation for switching between host and device modes." > > Sorry, can you send the patches to me, or point me to a git tree? I'm > not seeing that thread in my mailbox or on google. > >> Enable the power down on his devices. Let me know if you still see any >> issue. If there is no issue, please provide Tested-by tag. > > Would be happy to test it, thought I'm traveling tomorrow, so I may > not be able to validate till monday. > > thanks > -john > You can find the patch set following to this link. https://marc.info/?l=linux-usb&m=153745139408236&w=2 Regards, Artur
