[PATCH] Set default transfer size to 1024 bytes

Stefan Schmidt stefan at datenfreihafen.org
Tue Nov 9 21:43:44 CET 2010

On Mon, 2010-11-08 at 23:03, Tormod Volden wrote:
> On Mon, Nov 8, 2010 at 12:21 PM, Stefan Schmidt wrote:
> >> Hopefully my previous patch makes this default transfer size
> >> irrelevant in almost all cases :)
> >>
> >> Anyway, 1024 is a safer choice than 4096 which the previous
> >> logic would provide on most (Linux) boxen.
> >
> > Why do you think that 1024 is more safe here. I'm not really against this patch
> > and my testing showed that it breaks nothing for me but I wonder what it should
> > help.
> As hinted in the FIXME below, the DFU standard says the effective
> transfer size can be chosen from bMaxPacketSIze0 (often 64) up to the
> real wTransferSize in the device. If we do not know the real value of
> wTransferSize, going lower can only be safer.

And potential slower. :)

I agree that it is not really good to set the value to high. I just did another
test with this patch applied and did not spot any slowdown though :)

Should be fine to go in.

> I would guess that among
> the broken devices where we can not read out wTransferSize, some have
> little RAM and hence a small receive buffer. But how low should we go?
> At least 1k should be better than 4k for these reasons. And it matches
> the flash page size for many devices, if that is a factor. When I
> first saw the "page_size" in the code I thought it referred to this, I
> do not know if that was the intention at some point.

Flash page size is a good point here I haven't thought to much about. Lets get
this in.

> But again, I hope my previous patch will squeeze the real
> wTransferSize out of most devices.
> >
> >> -     if (transfer_size > page_size)
> >> -             transfer_size = page_size;
> >> +     /* FIXME: Ensure bMaxPacketSize0 <= transfer_size <= wTransferSize */
> >
> > I was hoping we could reduce the FIXMEs instead adding new ones. :)
> We will eventually :) But for now it is better to have it documented
> in the code than in my private to-do list.

OK, leave it. Care to also add oit to the project todo list in the git repo?

Stefan Schmidt

More information about the devel mailing list