From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH v2 0/5] arm/early-printk: Improve reusability and add Calxeda support Date: Thu, 30 May 2013 11:14:47 +0200 Message-ID: <51A71887.1010108@calxeda.com> References: <1369403250-9132-1-git-send-email-andre.przywara@calxeda.com> <1369904360.13087.40.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1369904360.13087.40.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "julien.grall@linaro.org" , "xen-devel@lists.xen.org" , "stefano.stabellini@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org On 05/30/2013 10:59 AM, Ian Campbell wrote: > On Fri, 2013-05-24 at 15:47 +0200, Andre Przywara wrote: >> The current early-printk support for ARM is rather hard-coded, making >> it hard to add machines or tweak settings. >> This series slightly moves some code to gather UART settings in >> xen/arch/arm/Rules.mk instead of the actual .c files. Also it allows >> two different machines with different settings to share the same >> driver, which the last patch exploits to add support the Calxeda >> Midway hardware. >> >> This haven't been extensively tested, but I looked at the generated >> assembly and did some quick checks on Versatile Express. >> >> Signed-off-by: Andre Przywara > > All Acked + applied, thanks. Thanks! > I did wonder vaguely about: > > pulling the per board configs out of Rules.mk into > earlyprintk-.mk and doing: > ifneq($(CONFIG_EARLY_PRINTK),) > include earlyprintk-$(CONFIG_EARLY_PRINTK).mk > endif Yeah, I also found it being in kind of the wrong place. Just wasn't sure if early_printk justifies extra files to be created. What about moving all the boards definitions into one file and including this? This keeps Rules.mk clean and avoids too much clutter. > and > > using the presence or absence of EARLY_PRINTK_BAUD instead of using a > separate EARLY_PRINTK_INIT_UART. I was also wondering about this redundancy, this seems to be a nice solution for this. Thanks, will make a patch. Regards, Andre.