On Sunday, October 25, 2015 at 03:55:43 PM, Siarhei Siamashka wrote:
On Sun, 25 Oct 2015 12:00:09 +0100
Marek Vasut marex@denx.de wrote:
On Sunday, October 25, 2015 at 05:44:47 AM, Siarhei Siamashka wrote:
This is necessary to distinguish between the "dfu-util --detach" and the "dfu-util --reset" requests.
The default weak implementation of dfu_usb_get_reset() unconditionally reboots the device, but we want to be able to continue the boot.scr execution after writing the kernel, fdt and ramdisk to RAM via DFU.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com
drivers/usb/musb-new/sunxi.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c index a146c08..5eb8d19 100644 --- a/drivers/usb/musb-new/sunxi.c +++ b/drivers/usb/musb-new/sunxi.c @@ -166,6 +166,17 @@ static void USBC_ConfigFIFO_Base(void)
}
/*********************************************************************
***** + * Needed for the DFU polling magic
*** ****/ + +static u8 last_int_usb;
+bool dfu_usb_get_reset(void) +{
- return !!(last_int_usb & MUSB_INTR_RESET);
The !! is not needed.
Thanks for your comment, I can surely change this in the updated version of the patch.
But I'm more interested to know if the USB people are happy with the current wacky way of interaction between the DFU code and the USB drivers. Doing dfu_usb_get_reset() polling up to 1000 times in a loop does not look exactly beautiful:
https://github.com/u-boot/u-boot/blob/v2015.10/common/cmd_dfu.c#L64It might be also a bit racy (the RESET interrupt could be potentially missed sometimes).
That's a question for Lukasz .
Best regards, Marek Vasut