No subject

struct qTD {
=09/* this part defined by EHCI spec */
=09uint32_t qt_next;=09=09/* see EHCI 3.5.1 */
#define=09QT_NEXT_TERMINATE=091
=09uint32_t qt_altnext;=09=09/* see EHCI 3.5.2 */
=09uint32_t qt_token;=09=09/* see EHCI 3.5.3 */
=09uint32_t qt_buffer[5];=09=09/* see EHCI 3.5.4 */
=09uint32_t qt_buffer_hi[5];=09/* Appendix B */
=09/* pad struct for 32 byte alignment */
=09uint32_t unused[3];
};

So sizeof(struct qTD) is 16 * 32 bits =3D 64 bytes. For the worst alignment=
 case,
the number of qTDs to allocate for 65535 blocks of 512 bytes (worst MSC cas=
e
with 512-byte sectors) is DIV_ROUND_UP(65535 * 512, 4 * 4096) =3D 2048 qTDs=
, i.e.
128 kiB. For the same transfer size with the best alignment case, it is
DIV_ROUND_UP(65535 * 512, 5 * 4096) =3D 1639 qTDs, i.e. 104896 B.

But if we consider extreme cases, these figures can get even larger, e.g. w=
ith
4-kiB storage sectors.

So we could perhaps issue a #error in ehci-hcd or in usb_storage if
CONFIG_SYS_MALLOC_LEN is not large enough, but I don't think it's a good id=
ea
because:
 - the threshold value would have to depend on runtime block sizes or somet=
hing,
   which could lead to a big worst worst case that would almost never happe=
n in
   real life, so giving such an unrealistic heap size constraint would be
   cumbersome,
 - reaching the top sizes would mean reading a huge file or something to a =
large
   buffer (much larger than the qTDs this transfer requires), which would v=
ery
   likely be heap-allocated (except for commands like fatload), so
   CONFIG_SYS_MALLOC_LEN would already have to be large for the application=
,
 - for command line operations like fatload, transfers of uncontrolled leng=
ths
   could simply crash U-Boot if they go too far in memory, which means that
   users of such commands need to know what they are doing anyway, so they =
have
   to control transfer sizes,
 - there is already a runtime error displayed in case of allocation failure=
.

Marek, what do you think?

Best regards,
Beno=C3=AEt