From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752481AbbBSEzX (ORCPT <rfc822;w@1wt.eu>);
	Wed, 18 Feb 2015 23:55:23 -0500
Received: from pmta2.delivery2.ore.mailhop.org ([54.69.130.42]:46064 "EHLO
	pmta2.delivery2.ore.mailhop.org" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1751734AbbBSEzV (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 18 Feb 2015 23:55:21 -0500
X-Mail-Handler: DuoCircle Outbound SMTP
X-Originating-IP: 104.193.169.186
X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information)
X-MHO-User: U2FsdGVkX18PTo9VHZtQ9w2LHQOwKN0T
Date: Wed, 18 Feb 2015 20:50:48 -0800
From: Tony Lindgren <tony@atomide.com>
To: Pali =?utf-8?B?Um9ow6Fy?= <pali.rohar@gmail.com>
Cc: linux-omap@vger.kernel.org, Kevin Hilman <khilman@kernel.org>,
        Aaro Koskinen <aaro.koskinen@iki.fi>,
        Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>,
        linux-kernel@vger.kernel.org,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
        Nishanth Menon <nm@ti.com>
Subject: Re: [PATCH] ARM: dts: Revert disabling of smc91x for n900
Message-ID: <20150219045047.GE32521@atomide.com>
References: <20150105230228.GO4081@atomide.com>
 <201502182004.03195@pali>
 <20150218224206.GC32521@atomide.com>
 <201502182352.16203@pali>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <201502182352.16203@pali>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

* Pali Rohár <pali.rohar@gmail.com> [150218 15:58]:
> On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote:
> > Of course it's always possible to do do a omap3-n900-qemu.dts
> > if larger changes are needed :)
>
> I would like to avoid using separate DTS for qemu. When we have 
> only one DTS file (for both qemu and real HW), we can test for 
> regression in qemu and we are sure that we have same software 
> configuration...

Agreed, and I'd rather take the extra warning on rare to find
hardware to avoid an etra .dts file.

Are there any reasons whey the n900 qemu support could not
be in the mainline qemu btw?

Regards,

Tony