Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752442AbbHGKuY (ORCPT ); Fri, 7 Aug 2015 06:50:24 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:43157 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751791AbbHGKuW (ORCPT ); Fri, 7 Aug 2015 06:50:22 -0400 X-Listener-Flag: 11101 Message-ID: <1438944618.14580.5.camel@mtksdaap41> Subject: Re: [PATCH v3 0/5] Add SMP bringup support for mt65xx socs From: Yingjoe Chen To: Russell King - ARM Linux CC: Matthias Brugger , , Arnd Bergmann , Stephen Boyd , , Rob Herring , , Sascha Hauer , Olof Johansson , , Date: Fri, 7 Aug 2015 18:50:18 +0800 In-Reply-To: <20150805223115.GD7557@n2100.arm.linux.org.uk> References: <1436851111-2369-1-git-send-email-yingjoe.chen@mediatek.com> <4831607.pyCH8elj8i@ubix> <20150805223115.GD7557@n2100.arm.linux.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1933 Lines: 50 On Wed, 2015-08-05 at 23:31 +0100, Russell King - ARM Linux wrote: > On Wed, Aug 05, 2015 at 08:44:11PM +0200, Matthias Brugger wrote: > > On Tuesday, July 14, 2015 01:18:26 PM Yingjoe Chen wrote: > > > This series add SMP brinup support for MediaTek SoCs. This is based > > > on v4.2-rc1 and Matthias' next branch (for dts parts). <...> > > Applied to v4.2-next/soc-2 and v4.2-next/dts-2 > > I've just NAK'd one of the patches in this set; I don't tend to even see > mediatek patches normally, as they all head into my junk mailfolder > because mediatek's mail server setup is truely abysmal (it has broken > reverse DNS - the DNS positively says that the mail server is not a > legit owner of the name it claims to be.) Hi Russell, Hope you see this. Thanks for your review. I already pass this information to our IT, hope they can resolve this soon. > The problem is that this patch series uses memblock_reserve() way after > the memory has been transitioned out of memblock's control, so actually > this has no effect. > > I've seen a number of patches doing this. I'm not sure what's soo friggin > hard for people to understand: memblock is about the EARLY stages of > getting the system up and running. Once the memory has been handed > over to the kernel's memory management, memblock MUST NOT BE USED to > reserve memory. > > There is one place, and one place only in the ARM kernel where > memblock_reserve() is possible, and that's in the ->reserve machine > callback. NOWHERE ELSE is permissible. It seems we can write memory-reserve node in device tree to do this as well. Do you prefer us to reserve memblock in reserve callback or using device tree? Joe.C -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/