From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Wed, 09 Sep 2015 08:51:09 +0200 Subject: [U-Boot] [PATCH 07/10] ARM: tegra: fix malloc region sizing In-Reply-To: <55EF5886.3020802@nvidia.com> References: <1441425831-3441-1-git-send-email-swarren@wwwdotorg.org> <1441425831-3441-7-git-send-email-swarren@wwwdotorg.org> <55EF56FF.9090803@wwwdotorg.org> <55EF5886.3020802@nvidia.com> Message-ID: <20150909085109.65b75bad@amdc2363> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Stephen, > On 09/08/2015 02:45 PM, Stephen Warren wrote: > > On 09/08/2015 09:53 AM, Tom Warren wrote: > >> Stephen, > >> > >> Stephen Warren wrote at Friday, September 04, 2015 9:04 PM: > >>> From: Stephen Warren > >>> > >>> Commit 52a7c98a1772 "tegra-common: increase malloc pool len by > >>> dfu mmc file buffer size" updated the definition of > >>> CONFIG_SYS_MALLOC_LEN for Tegra to take account of the DFU buffer > >>> size. However, this change had no effect, since typical Tegra > >>> board config headers don't set the DFU- related defines until > >>> after tegra-common.h is included. Fix this by moving the affected > >>> conditional code to tegra-common-post.h, which is included last. > >>> Also move the definition of SYS_NONCACHED_MEMORY since it's a > >>> related and adjacent definition. > >>> > >>> Fix the condition to test for the DFU feature, rather than > >>> specifically MMC DFU support, so it applies in all cases. > >>> > >>> Signed-off-by: Stephen Warren > >> > >> Do you want me to take these last four in to u-boot-tegra for the > >> pending PR, or do you expect them to go in another way? > > > > I believe the 4 "ARM: tegra:" patches can go through the Tegra tree > > since they're independent from the other patches in the series. > > Thanks. > > I note that Lukasz has ack'd all the other patches, so perhaps you can > just take the whole series through the Tegra tree? At least the DFU > patches since he's maintainer there. I personally would opt for applying this series to one tree. I've already ack'ed those patches, so those can go to any other tree (or even -dfu one when nobody wants to pick them :-)). > Perhaps TomR can ack the ext4 > patches since they don't seem to have a maintainer. Lack of FS (FAT, EXT4) maintainer is PITTA. I hope that somebody would step up for this position. -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group