From mboxrd@z Thu Jan 1 00:00:00 1970 From: Date: Mon, 05 Dec 2011 12:53:56 -0000 Subject: No subject Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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