mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Cerrato Renaud <r.cerrato@til-technologies.fr>
To: barebox@lists.infradead.org
Subject: [PATCH 5/5] dfu: usb reset state workaround
Date: Wed, 13 Mar 2013 14:46:37 +0100	[thread overview]
Message-ID: <5140833D.3080303@til-technologies.fr> (raw)

When an USB_REQ_DFU_DETACH request is received, the device state switch to DFU_STATE_appDETACH, and then wait for an usb reset to switch to DFU_STATE_dfuIDLE (through dfu_disable() being called). 

I noticed that using dfu-util v0.7 on my AT91SAM9260 board, the programming failed because of the device not entering the DFU_STATE_dfuIDLE after an usb reset (staying in the DFU_STATE_appDETACH state).

According to the current implementation, once the USB_REQ_DFU_DETACH is sent and right after the usb reset, if the DFU client set more than one configuration (by iterating over them for example), the device state will reset to the DFU_STATE_appDETACH state on the 2nd iteration because of the following line in set_config (composite.c, line 362) :

...
if(cdev->config) 
    reset_config();   // will call dfu_disable() again!
...

The attached patch is a *try* to fix the issue by leaving the device in the DFU_STATE_dfuIDLE state after an usb reset if already in that state. dfu-util will complain about the device already in the DFU_STATE_dfuIDLE on the next start, but everything is still working and thus usable.

This may need a REVISIT, but since the dfu_disable() gets called on both configuration change and usb reset, we can't fix this easily for now..

Signed-off-by: Cerrato Renaud <r.cerrato@til-technologies.fr>
---
 drivers/usb/gadget/dfu.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/dfu.c b/drivers/usb/gadget/dfu.c
index e051879..e4af567 100644
--- a/drivers/usb/gadget/dfu.c
+++ b/drivers/usb/gadget/dfu.c
@@ -514,14 +514,12 @@ static void dfu_disable(struct usb_function *f)
     struct f_dfu        *dfu = func_to_dfu(f);
 
     switch (dfu->dfu_state) {
+    case DFU_STATE_dfuIDLE:
     case DFU_STATE_appDETACH:
         dfu->dfu_state = DFU_STATE_dfuIDLE;
         break;
-    case DFU_STATE_dfuMANIFEST_WAIT_RST:
-        dfu->dfu_state = DFU_STATE_appIDLE;
-        break;
     default:
-        dfu->dfu_state = DFU_STATE_appDETACH;
+        dfu->dfu_state = DFU_STATE_appIDLE;
         break;
     }
 
-- 
1.7.2.5


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

                 reply	other threads:[~2013-03-13 13:45 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5140833D.3080303@til-technologies.fr \
    --to=r.cerrato@til-technologies.fr \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox