From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chee, Tien Fong <tien.fong.chee@intel.com>
Date: Thu, 21 Feb 2019 08:40:31 +0000
Subject: [U-Boot] [U-Boot, v3,
 1/2] fs: fat: dynamically allocate memory for temporary buffer
In-Reply-To: <93ee9878-6739-95d4-2abd-6fdaec02ceae@suse.de>
References: <1549868180-21635-1-git-send-email-tien.fong.chee@intel.com>
 <20190220015744.GN21737@bill-the-cat>
 <6e8f32fe-f956-3b7a-d492-9f99dc3f41e3@monstr.eu>
 <1550737386.9880.8.camel@intel.com>
 <93ee9878-6739-95d4-2abd-6fdaec02ceae@suse.de>
Message-ID: <1550738431.9880.11.camel@intel.com>
List-Id: <u-boot.lists.denx.de>
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 09:29 +0100, Alexander Graf wrote:
> 
> On 21.02.19 09:23, Chee, Tien Fong wrote:
> > 
> > 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 <tien.fong.chee@intel.com>
> > > > > 
> > > > > 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 <stefan.ag...@toradex.com>
> > > > > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > 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?
> You already received feedback that it does break ZynqMP, so the
> current
> approach won't work.
> 
> How about you create a new kconfig option that allows you to say
> whether
> you want to use malloc or .bss for temporary data in the FAT driver.
> You
> can then have an _SPL_ version of that kconfig and check for it with
> IS_ENABLED() which should automatically tell you the right answer
> depending on whether you're in an SPL build or not.
> 
> Then you can set the SPL version to default malloc and the non-SPL
> version to default .bss.
Marek and Tom rini,

Are you guys okay with Alex's suggestion?
> 
> That should give you the fix you want, without the problems it
> introduces for SPL (where malloc space is really constrained, and
> discouraged to use because you can't check whether it fits at compile
> time).
> 
> 
> Alex

Thanks.
TF.