[PATCH] main: New default (1024) and clamping of transfer size

Stefan Schmidt stefan at datenfreihafen.org
Sat Nov 13 22:51:14 CET 2010

On Sat, 2010-11-13 at 10:37, Tormod Volden wrote:
> From: Tormod Volden <debian.tormod at gmail.com>
> DFU dictates that the effective transfer size is chosen from
> bMaxPacketSIze0 (often 64) up to the real wTransferSize in the device.
> If we can not detect the real value of wTransferSize, lower guesses can
> only be safer. The previous default was the host kernel page size which
> is the higher limit on the host side (on Linux). This would usually
> translate into 4096, which possibly is too high for some devices.
> 1024 bytes seems like a reasonable trade-off for a default size, when
> one is needed. At any rate, it should really be determined from the DFU
> functional descriptor, so this default should not matter much.

Applied, thanks.

Had to manually fix one hunk per hand due to other changes. Please crosscheck.

I like this solution as it covers all cases so far.

> Digging through the git/svn log, I found the explanation for clamping
> transfer size to host kernel page_size:
> http://git.openezx.org/dfu-util.git?a=commitdiff;h=e62a198670accf9e47176ba6434c84c41df32201
> So I have left this check in (and documented it better).

Good. Thanks for digging through this.

> Does anyone know if USB control transfers are still limited to the kernel
> page size on Linux? Is it Linux-only?

No idea. Would be good to find out. At least I heard somebody used it on MAC OSX
and also on windows.

> In any case, I am pretty convinced we should not /default/ to the host
> kernel page_size.

Agreed. Keep it as upper bound host limit is fine.

> Also got rid of the FIXME in this version :)


Stefan Schmidt

More information about the devel mailing list