Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964829AbcCQO1a (ORCPT ); Thu, 17 Mar 2016 10:27:30 -0400 Received: from foss.arm.com ([217.140.101.70]:48457 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932313AbcCQO1W (ORCPT ); Thu, 17 Mar 2016 10:27:22 -0400 Date: Thu, 17 Mar 2016 14:27:16 +0000 From: Catalin Marinas To: Timur Tabi Cc: linux-arm-kernel@lists.infradead.org, Ganesh Mahendran , Will Deacon , linux-kernel@vger.kernel.org, stable@vger.kernel.org, rrichter@cavium.com, tchalamarla@cavium.com, apinski@cavium.com, Shanker Donthineni Subject: Re: [PATCH] Revert "arm64: Increase the max granular size" Message-ID: <20160317142716.GC11623@e104818-lin.cambridge.arm.com> References: <1458120743-12145-1-git-send-email-opensource.ganesh@gmail.com> <20160316100759.GA18387@arm.com> <56E95A4E.4050709@codeaurora.org> <20160316141802.GC13423@e104818-lin.cambridge.arm.com> <56E97B10.4050401@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E97B10.4050401@codeaurora.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 843 Lines: 19 On Wed, Mar 16, 2016 at 10:26:08AM -0500, Timur Tabi wrote: > Catalin Marinas wrote: > >Why do you need your own defconfig? If it's just on the short term until > >all your code is upstream, that's fine, but this goes against the single > >Image aim. I would like defconfig to cover all supported SoCs (and yes, > >ACPI on by default once we deem it !EXPERT anymore), though at some > >point we may need a server/mobile split (if the generated image is too > >large, maybe more stuff being built as modules). > > Yes, that's exactly it. Ours is an ACPI system, and so we have to have our > own defconfig for now. We're holding off on pushing our own defconfig > changes (enabling drivers, etc) until ACPI is enabled in > arch/arm64/configs/defconfig. Is there anything that prevents you from providing a dtb/dts for this SoC? -- Catalin