From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chee, Tien Fong Date: Thu, 21 Feb 2019 08:23:07 +0000 Subject: [U-Boot] [U-Boot, v3, 1/2] fs: fat: dynamically allocate memory for temporary buffer In-Reply-To: <6e8f32fe-f956-3b7a-d492-9f99dc3f41e3@monstr.eu> References: <1549868180-21635-1-git-send-email-tien.fong.chee@intel.com> <20190220015744.GN21737@bill-the-cat> <6e8f32fe-f956-3b7a-d492-9f99dc3f41e3@monstr.eu> Message-ID: <1550737386.9880.8.camel@intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, 2019-02-21 at 08:45 +0100, Michal Simek wrote: > Hi Tom, > > On 20. 02. 19 2:58, Tom Rini wrote: > > > > On Mon, Feb 11, 2019 at 02:56:19PM +0800, tien.fong.chee at intel.com > > wrote: > > > > > > > > From: Tien Fong Chee > > > > > > Drop the statically allocated get_contents_vfatname_block and > > > dynamically allocate a buffer only if required. This saves > > > 64KiB of memory. > > > > > > Signed-off-by: Stefan Agner > > > Signed-off-by: Tien Fong Chee > > Applied to u-boot/master, thanks! > please remove this patch (better both of them because they were in > series) I think patch 2/2 should be safe, because no memory size is changed. Basically, it just to release the allocated memory immediately when it's not required, so other can re-use it. > because they are breaking at least ZynqMP SPL. It is also too > late in cycle to create random fix. > > You can't simply move 64KB from code to malloc without reflecting > this > by changing MALLOC space size. > > Other boards with SPL fat could be also affected by this if they > don't > allocate big malloc space. So, any suggestion to get the patch 1/2 accepted? inform all board maintainers to test it out? > > Thanks, > Michal > Thanks, Tien Fong.