[PATCH] Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid"

This reverts commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3. Turns out that commit is wrong. Host controllers are allowed to use Clear Feature HALT as means to sync data toggle between host and periperal. Cc: Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 5 - 1 file

Re: 答复: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

Hi, Thinh Nguyen writes: >>> It means that the mainline keep checking stall status first before >>> handle clear-halt request? as usb spec, it's actually okay to send >>> Clear Halt at any time. But dwc3 core hanging with macOS adb >>> application, so I th

Re: 答复: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

Hi Felipe, On 6/28/2018 11:24 PM, Felipe Balbi wrote: > (no top-posting!!) > > liangshengjun writes: > >> Hi balbi, >> >> It means that the mainline keep checking stall status first before >> handle clear-halt request? as usb spec, it's actually okay to send

Re: 答复: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

(no top-posting!!) liangshengjun writes: > Hi balbi, > > It means that the mainline keep checking stall status first before > handle clear-halt request? as usb spec, it's actually okay to send > Clear Halt at any time. But dwc3 core hanging with macOS adb > appli

答复: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

Hi balbi, It means that the mainline keep checking stall status first before handle clear-halt request? as usb spec, it's actually okay to send Clear Halt at any time. But dwc3 core hanging with macOS adb application, so I think there is other rootcase why dwc3 hanging , and current patch

答复: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

@vger.kernel.org; Alan Stern 主题: Re: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid] Hi, please don't top-post and break your emails at 80 columns liangshengjun writes: > Hi balbi, > > Thanks for reponse. Now I fixed this case without check STALL >

Re: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

Hi, please don't top-post and break your emails at 80 columns liangshengjun writes: > Hi balbi, > > Thanks for reponse. Now I fixed this case without check STALL > status when clear-Halt request. > > BDW, I have meet other case: > > Run dwc3 for uvc func

Re: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

Hi balbi, Thanks for reponse. Now I fixed this case without check STALL status when clear-Halt request. BDW, I have meet other case: Run dwc3 for uvc function, the uvc video show video overlapping when windows 7 restart camera app. I debug the dwc3 drivers ,found : 1. when

Re: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

Hi, Alan Stern writes: >> that patch is not 100% correct. You can revert it in your tree. I added >> that because of a problem I found when running adb against macOS. >> >> It's actually okay to send Clear Halt at any time, but for some reason >> dwc3 was hanging

Re: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

On Thu, 21 Jun 2018, Felipe Balbi wrote: > > Hi, > > that patch is not 100% correct. You can revert it in your tree. I added > that because of a problem I found when running adb against macOS. > > It's actually okay to send Clear Halt at any time, but for some reason &g

Re: make a confirm for [usb: dwc3: gadget: skip Set/Clear Halt when invalid]

Hi, that patch is not 100% correct. You can revert it in your tree. I added that because of a problem I found when running adb against macOS. It's actually okay to send Clear Halt at any time, but for some reason dwc3 was hanging when running adb against macOS. If you can revert the patch

Re: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

Hi, John Youn writes: >> Felipe Balbi writes: >>> At least macOS seems to be sending >>> ClearFeature(ENDPOINT_HALT) to endpoints which >>> aren't Halted. This makes DWC3's CLEARSTALL command >>> time out which causes several issues for the

Re: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

On 04/04/2017 01:09 AM, Felipe Balbi wrote: > > Hi John, > > Felipe Balbi writes: >> At least macOS seems to be sending >> ClearFeature(ENDPOINT_HALT) to endpoints which >> aren't Halted. This makes DWC3's CLEARSTALL command >> time out which causes several issues

Re: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

Hi John, Felipe Balbi writes: > At least macOS seems to be sending > ClearFeature(ENDPOINT_HALT) to endpoints which > aren't Halted. This makes DWC3's CLEARSTALL command > time out which causes several issues for the driver. > > Instead, let's just return 0 and

RE: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

Hi, Felipe Balbi writes: >>> I've been looking at this and based on sniffer and dwc3 tracepoints, it >>> seems like dwc3 is behaving properly. The real issue seems to be that >>> g_mass_storage isn't queueing a new request to IN endpoint. >>> >>> I'll continue

RE: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

Hi, Felipe Balbi writes: >> Thinh Nguyen writes: drivers/usb/dwc3/gadget.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index

RE: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

Hi Thinh, Thinh Nguyen writes: >> drivers/usb/dwc3/gadget.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >> index 6faf484e5dfc..0a664d8eba3f 100644 >> --- a/drivers/usb/dwc3/gadget.c >> +++

RE: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

Felipe Balbi writes: > Hi Thinh, > > Thinh Nguyen writes: >>> drivers/usb/dwc3/gadget.c | 5 + >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >>> index

[PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

At least macOS seems to be sending ClearFeature(ENDPOINT_HALT) to endpoints which aren't Halted. This makes DWC3's CLEARSTALL command time out which causes several issues for the driver. Instead, let's just return 0 and bail out early. Cc: Signed-off-by: Felipe Balbi

Re: [PATCH 4/4] cdc-acm: clear halt condition

On Mon, 2016-11-07 at 11:50 +0100, Ladislav Michl wrote: > On Mon, Nov 07, 2016 at 11:26:10AM +0100, Oliver Neukum wrote: > > This is looking good. Please resend so Greg can pick it up. > > One more question. I rather point on it explicitely as it changes > driver behaviour. Previously, urb was

Re: [PATCH 4/4] cdc-acm: clear halt condition

On Mon, Nov 07, 2016 at 11:26:10AM +0100, Oliver Neukum wrote: > This is looking good. Please resend so Greg can pick it up. One more question. I rather point on it explicitely as it changes driver behaviour. Previously, urb was submitted again only on status == 0. This caused driver to run out

Re: [PATCH 4/4] cdc-acm: clear halt condition

On Sun, 2016-11-06 at 23:31 +0100, Ladislav Michl wrote: > On Sun, Nov 06, 2016 at 10:30:02PM +0100, Oliver Neukum wrote: > > Hi, > > > > almost. Two issues left with this section. > > > > 1. It makes no sense to check the results of usb_clear_halt() > > If it fails, we cannot do anything

Re: [PATCH 4/4] cdc-acm: clear halt condition

e work queue > is executed. pre_reset() needs to clear the flag EVENT_RX_STALL. Hi, thanks for feedback. Here's an update: -- >8 -- Subject: [PATCHv3 4/4] cdc-acm: clear halt condition Signed-off-by: Ladislav Michl <la...@linux-mips.org> --- drivers/usb/class/cdc-acm.c | 59 +++

Re: [PATCH 4/4] cdc-acm: clear halt condition

On Sun, 2016-11-06 at 10:07 +0100, Ladislav Michl wrote: > + if (test_bit(EVENT_RX_STALL, >flags)) { > + status = usb_autopm_get_interface(acm->data); > + if (!status) { > + for (i = 0; i < acm->rx_buflimit; i++) { > +

Re: [PATCH 4/4] cdc-acm: clear halt condition

t; > + if (!status) > > + acm_submit_read_urbs(acm, GFP_KERNEL); > > No, you would kill the device. Either do it all conditionally > or nothing. I do not follow. Did you mean something like this? -- >8 -- Subject: [PATCHv2 4/4] cdc-acm: clear

Re: [PATCH 4/4] cdc-acm: clear halt condition

On Sun, 2016-11-06 at 01:36 +0100, Ladislav Michl wrote: > > @@ -475,7 +490,30 @@ static void acm_softint(struct work_struct *work) > { > struct acm *acm = container_of(work, struct acm, work); > > - tty_port_tty_wakeup(>port); > + dev_vdbg(>data->dev, "scheduled work\n"); > + >

[PATCH 4/4] cdc-acm: clear halt condition

Signed-off-by: Ladislav Michl --- drivers/usb/class/cdc-acm.c | 54 ++--- drivers/usb/class/cdc-acm.h | 3 +++ 2 files changed, 49 insertions(+), 8 deletions(-) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c

Re: clear halt

[quoted lines by Greg KH on 2016/06/05 at 14:23 -0700] >> Using USBFS: If a device doesn't support clear halt (or, perhaps, not >> properly), is there an alternative? For example, is there a way to ask which >> state the device's data toggle is in and then tell the host what

Re: clear halt

On Sun, Jun 05, 2016 at 05:00:12PM -0400, Dave Mielke wrote: > Using USBFS: If a device doesn't support clear halt (or, perhaps, not > properly), is there an alternative? For example, is there a way to ask which > state the device's data toggle is in and then tell the host what state to

clear halt

Using USBFS: If a device doesn't support clear halt (or, perhaps, not properly), is there an alternative? For example, is there a way to ask which state the device's data toggle is in and then tell the host what state to reset its end to? -- Dave Mielke | 2213 Fox Crescent

[PATCH v2 02/12] usb: dwc2: gadget: fix clear halt feature handling

From: Gregory Herrero gregory.herr...@intel.com When clearing HALT on an endpoint, req-complete of in progress requests must be called with locks off. New request should only be started if there is not already a pending request on the endpoint. Tested-by: Robert Baldyga r.bald...@samsung.com

[PATCH v1 03/13] usb: dwc2: gadget: fix clear halt feature handling

From: Gregory Herrero gregory.herr...@intel.com When clearing HALT on an endpoint, req-complete of in progress requests must be called with locks off. New request should only be started if there is not already a pending request on the endpoint. Signed-off-by: Gregory Herrero

RE: [PATCH 03/13] usb: dwc2: gadget: fix clear halt feature handling

...@opensource.altera.com Subject: Re: [PATCH 03/13] usb: dwc2: gadget: fix clear halt feature handling Hello. Hi, Thank you for reviewing these patches! On 01/15/2015 08:09 PM, Mian Yousaf Kaukab wrote: From: Gregory Herrero gregory.herr...@intel.com When clearing HALT on an endpoint

[PATCH 03/13] usb: dwc2: gadget: fix clear halt feature handling

From: Gregory Herrero gregory.herr...@intel.com When clearing HALT on an endpoint, in progress requests must be called with locks off. Request must be started only if there is not already a pending request on the endpoint caused by previous completion. Signed-off-by: Gregory Herrero

Re: [PATCH 03/13] usb: dwc2: gadget: fix clear halt feature handling

Hello. On 01/15/2015 08:09 PM, Mian Yousaf Kaukab wrote: From: Gregory Herrero gregory.herr...@intel.com When clearing HALT on an endpoint, in progress requests must be called with locks off. Requests must be *called*? Request must be started only if there is not already a pending

Re: [PATCH] usbhid: improve handling of Clear-Halt and reset

On Tue, 2014-09-02 at 11:39 -0400, Alan Stern wrote: This patch changes the way usbhid carries out Clear-Halt and reset. Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver immediately restarts the interrupt URB, even if the Clear-Halt failed. This doesn't work out well

Re: [PATCH] usbhid: improve handling of Clear-Halt and reset

On Tue, 2 Sep 2014, Alan Stern wrote: This patch changes the way usbhid carries out Clear-Halt and reset. Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver immediately restarts the interrupt URB, even if the Clear-Halt failed. This doesn't work out well when the reason

Re: [PATCH] usbhid: improve handling of Clear-Halt and reset

On Wed, 3 Sep 2014, Alan Stern wrote: What happens if we lose events? Especially with keyboards I see a problem with dropping a release event because this will trigger autorepeat. So should we generate a release event for all pressed keys on reset? That's a separate issue, not directly

[PATCH] usbhid: improve handling of Clear-Halt and reset

This patch changes the way usbhid carries out Clear-Halt and reset. Currently, after a Clear-Halt on the interrupt-IN endpoint, the driver immediately restarts the interrupt URB, even if the Clear-Halt failed. This doesn't work out well when the reason for the failure was that the device

Re: XHCI Clear halt issue

this, but I have not seen a firm conclusion. It seems that some of the early responses by Sarah Sharp indicate that it is working this way by design (I admit I am not an expert in the XHCI spec). I see some newer posts referencing a clear halt bug, but I have been unable to find what this definitively

Re: XHCI Clear halt issue

Thanks for your help, Mathias! See my comments inline below: Mathias Nyman mathias.ny...@linux.intel.com wrote on 04/08/2014 10:26:43 AM: The issue we currently have is that the xHCI (both driver and hw) refuses to reset an endpoint if it's not halted. SetFeature(ENDPOINT_HALT) will set the

XHCI Clear halt issue

conclusion. It seems that some of the early responses by Sarah Sharp indicate that it is working this way by design (I admit I am not an expert in the XHCI spec). I see some newer posts referencing a clear halt bug, but I have been unable to find what this definitively is referencing. Based on my

Re: status of the xHCI clear halt bug?

On 03/20/2014 11:10 PM, Sarah Sharp wrote: On Sun, Mar 16, 2014 at 07:52:30PM +0100, Martin Dauskardt wrote: Hi Sarah, I lost track on this issue. Is there a final patch? Is it ready for integration into the kernel? Is there any kernel version that includes a fix? Is there any timeline?

Re: status of the xHCI clear halt bug?

On Sun, Mar 16, 2014 at 07:52:30PM +0100, Martin Dauskardt wrote: Hi Sarah, I lost track on this issue. Is there a final patch? Is it ready for integration into the kernel? Is there any kernel version that includes a fix? Is there any timeline? Mathias was working on this fix, but wanted to

[PATCH 2/2] usb: usbtest: Always clear halt else further tests will fail

); - if (retval 0) + if (retval 0) { + int ret; + + /* clear halt anyways, else further tests will fail */ + ret = usb_clear_halt(urb-dev, urb-pipe); + if (ret) + ERROR(tdev, ep %02x couldn't clear halt, %d\n

Re: [PATCH 2/2] usb: usbtest: Always clear halt else further tests will fail

, int ep, struct urb *urb) return retval; } retval = verify_halted(tdev, ep, urb); - if (retval 0) + if (retval 0) { + int ret; + + /* clear halt anyways, else further tests will fail */ + ret = usb_clear_halt(urb-dev

Re: [PATCH 2/2] usb: usbtest: Always clear halt else further tests will fail

0) + if (retval 0) { + int ret; + + /* clear halt anyways, else further tests will fail */ + ret = usb_clear_halt(urb-dev, urb-pipe); + if (ret) + ERROR(tdev, ep %02x couldn't clear halt, %d\n

Re: [PATCH 2/2] usb: usbtest: Always clear halt else further tests will fail

@@ -1545,8 +1545,17 @@ static int test_halt(struct usbtest_dev *tdev, int ep, struct urb *urb) return retval; } retval = verify_halted(tdev, ep, urb); - if (retval 0) + if (retval 0) { + int ret; + + /* clear halt anyways, else further tests

Re: [PATCH 2/2] usb: usbtest: Always clear halt else further tests will fail

On Thu, Dec 19, 2013 at 11:51:45AM +0530, Roger Quadros wrote: On 12/19/2013 11:16 AM, Huang Rui wrote: On Thu, Dec 19, 2013 at 12:01:47PM +0800, Huang Rui wrote: On Wed, Dec 18, 2013 at 03:40:11PM +0530, Roger Quadros wrote: In test_halt() we set an endpoint halt condition and return on

Re: Need testers for long-standing xHCI clear halt bug

unconditionally cleared a halt on all endpoints after the camera was closed. This triggered a bug in the xHCI driver, making it so gphoto2 couldn't talk to the device on a subsequent open. You worked around the issue by removing the clear halt in gphoto2. Now Xenia has a potential fix

Re: Need testers for long-standing xHCI clear halt bug

on a subsequent open. You worked around the issue by removing the clear halt in gphoto2. Now Xenia has a potential fix for that bug, and she needs help testing that fix. Would it be possible to add that clear halt back into gphoto2, apply the following two kernel patches, and make sure

Re: Need testers for long-standing xHCI clear halt bug

On Mon, Oct 14, 2013 at 04:01:31PM -0700, Sarah Sharp wrote: On Sat, Oct 12, 2013 at 09:25:17AM +0200, Marcus Meissner wrote: Hi Sarah, I built: - current kernel git with SUSE config - libgphoto2 with the clear_halt reenabled - rebooted gphoto2 now hangs on the second try

Re: Need testers for long-standing xHCI clear halt bug

on a subsequent open. You worked around the issue by removing the clear halt in gphoto2. Now Xenia has a potential fix for that bug, and she needs help testing that fix. Would it be possible to add that clear halt back into gphoto2, apply the following two kernel patches, and make sure

Re: Need testers for long-standing xHCI clear halt bug

couldn't talk to the device on a subsequent open. You worked around the issue by removing the clear halt in gphoto2. Now Xenia has a potential fix for that bug, and she needs help testing that fix. Would it be possible to add that clear halt back into gphoto2, apply the following two

Re: Need testers for long-standing xHCI clear halt bug

. This triggered a bug in the xHCI driver, making it so gphoto2 couldn't talk to the device on a subsequent open. You worked around the issue by removing the clear halt in gphoto2. Now Xenia has a potential fix for that bug, and she needs help testing that fix. Would it be possible to add

Need testers for long-standing xHCI clear halt bug

%40mail.gmail.comforum_name=libusbx-devel The issue was that gphoto2 unconditionally cleared a halt on all endpoints after the camera was closed. This triggered a bug in the xHCI driver, making it so gphoto2 couldn't talk to the device on a subsequent open. You worked around the issue by removing the clear halt

patch usb-usb-storage-don-t-clear-halt-when-get-max-lun-stalls.patch added to gregkh-2.6 tree

This is a note to let you know that I've just added the patch titled Subject: USB: usb-storage: don't clear-halt when Get-Max-LUN stalls to my gregkh-2.6 tree. Its filename is usb-usb-storage-don-t-clear-halt-when-get-max-lun-stalls.patch This tree can be found at http

[PATCH] usb-storage: don't clear-halt when Get-Max-LUN stalls

This patch (as1032) removes the Clear-Halt calls in usb_stor_Bulk_max_lun(). Evidently some devices (such as the Oracom MP3 player) really don't like to receive these requests when their bulk endpoints aren't halted. The only reason for adding them originally was to get an ancient ZIP-100 drive