From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 8 Sep 2015 14:56:36 -0700 Subject: [U-Boot] [PATCH 07/10] ARM: tegra: fix malloc region sizing In-Reply-To: <20150908215657.GG26226@bill-the-cat> 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> <20150908215657.GG26226@bill-the-cat> Message-ID: <55EF5994.2040107@nvidia.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 09/08/2015 02:56 PM, Tom Rini wrote: > On Tue, Sep 08, 2015 at 02:52:06PM -0700, Stephen Warren wrote: >> 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. Perhaps TomR >> can ack the ext4 patches since they don't seem to have a >> maintainer. > > I think I snagged them all in patchwork for myself. Do the Tegra > ones depend on anything else? I don't believe the Tegra patches depend on anything to compile or run; they're just all conceptually related to DFU support on Tegra.