[U-Boot] [PATCH] dfu: initial implementation

[Andrzej Pietrasiewicz]

Dear Wolfgang Denk,

Please see my comments inline.

> >
> > DFU is part of USB; an extension to be precise, but an extension
> bound
> > so tightly to the design and philosophy of USB that it is rather
> > inconceivable to separate the two.
> 
> Could you please be so kind and explain which exact issues you see for
> such a separation?

First of all, I think that it is more proper to speak of communications
part and state machine part. They are bound together by the standard.
For example, in the dfuIDLE state, the receipt of DFU_DNLOAD request
with wLength == 0 triggers a "device stalls the control pipe" action.
This kind of stuff is very USB specific - I am not sure what would
"the control pipe" be for serial/Ethernet, nor what "stall the
control pipe" would mean for either of them.
Another example, in the dfuMANIFEST state, when the status poll
timeout occurs and bitManifestationTolerant == 1 then "device can
still communicate via the USB".

The communications part is of course the very USB itself, so the only
thing which could be extracted is the state machine part. But, then,
in order not to be bound to USB but reusable, it should be abstract.
Being abstract, it would not be DFU anymore, but some
"Generic Update Protocol" that you have on your mind,
but we don't know of. Is there any standard for such a protocol?
 
> 
> > Seriously speaking, in view of ties between DFU and USB
> > IMHO it is impossible, or, at least, highly impractical.
> 
> Can you please support this statement with a few facts?

Please see my comment above.
 
> > > If my assumption is correct, then what would it take to split off
> > > protocol part and make it independent of the actual driver
> interface?
> >
> > I guess that in the situation given it would be of little use.
> 
> What do you think would be of little use?
> 

As far as I understand you correctly, you would like the state
machine code extracted from the initial DFU implementation posted
on this mailing list. And then you would like the DFU implemented
in terms of this abstract state machine. This means actually
more code, probably not a desired thing. The generic state machine
would also require some accompanying generic data structures,
and this would also mean code to translate back and forth between
USB/DFU (DFU _is_ USB) and state machine's data structures.
All in all, this means adding more complexity and code. This looks
like a premature optimization (which is widely known to be the root
of all evil), while at the moment, there are no use cases
to justify it. Should the use cases appear, the code can be reworked
based on the needs of both USB/DFU and new state machine users.

Regards,

Andrzej