From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:39842)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <glikely@secretlab.ca>) id 1RoJBU-0006vB-V8
	for qemu-devel@nongnu.org; Fri, 20 Jan 2012 13:27:33 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <glikely@secretlab.ca>) id 1RoJBQ-00064g-UG
	for qemu-devel@nongnu.org; Fri, 20 Jan 2012 13:27:32 -0500
Received: from mail-yw0-f45.google.com ([209.85.213.45]:40220)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <glikely@secretlab.ca>) id 1RoJBQ-00064c-Rv
	for qemu-devel@nongnu.org; Fri, 20 Jan 2012 13:27:28 -0500
Received: by yhr47 with SMTP id 47so495046yhr.4
	for <qemu-devel@nongnu.org>; Fri, 20 Jan 2012 10:27:28 -0800 (PST)
Sender: Grant Likely <glikely@secretlab.ca>
Date: Fri, 20 Jan 2012 11:27:25 -0700
From: Grant Likely <grant.likely@secretlab.ca>
Message-ID: <20120120182725.GV4223@ponder.secretlab.ca>
References: <1326213943-878-1-git-send-email-mark.langsdorf@calxeda.com>
	<1327008660-16789-1-git-send-email-mark.langsdorf@calxeda.com>
	<1327008660-16789-5-git-send-email-mark.langsdorf@calxeda.com>
	<CAFEAcA8U_Fr+gpJEw3H2=2HfUWa8qv_Prsk3XSXL2QiYRCHG+w@mail.gmail.com>
	<4F18A475.80009@calxeda.com>
	<CAFEAcA_McczeXEeGrS4NEp+a7iuxEeRJ1Ukq+pr6v_7sh5NLKA@mail.gmail.com>
	<4F197099.2020708@calxeda.com>
	<CAFEAcA9eV9PjyCFhH2CQ5D3Zx7kgj1qXm5gLFb_=pM6LVF61OQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAFEAcA9eV9PjyCFhH2CQ5D3Zx7kgj1qXm5gLFb_=pM6LVF61OQ@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>, i.mitsyanko@gmail.com, qemu-devel@nongnu.org, Rob Herring <rob.herring@calxeda.com>, edgar.iglesias@gmail.com, afaerber@suse.de

On Fri, Jan 20, 2012 at 01:57:29PM +0000, Peter Maydell wrote:
> On 20 January 2012 13:48, Rob Herring <rob.herring@calxeda.com> wrote:
> > Kernel DT co-maintainer is not authoritative enough for you?
> 
> Only if I recognise their name :-) [ie, sorry.]
> 
> > The documentation needs some clarification.
> >
> >> But this is an ABI between boot loaders and the kernel so I don't
> >> want to just have something random that happens to work. (And in
> >> particular if -1 is the officially sanctioned number then we need
> >> to fix arm_boot to be able to pass values >16 bits wide.)
> >>
> >
> > Here's were the kernel sets the mach #. nr is from the database for
> > non-DT and ~0 for DT machines.
> >
> > #define MACHINE_START(_type,_name)                      \
> > static const struct machine_desc __mach_desc_##_type    \
> >  __used                                                 \
> >  __attribute__((__section__(".arch.info.init"))) = {    \
> >        .nr             = MACH_TYPE_##_type,            \
> >        .name           = _name,
> >
> > #define MACHINE_END                             \
> > };
> >
> > #define DT_MACHINE_START(_name, _namestr)               \
> > static const struct machine_desc __mach_desc_##_name    \
> >  __used                                                 \
> >  __attribute__((__section__(".arch.info.init"))) = {    \
> >        .nr             = ~0,                           \
> >        .name           = _namestr,
> >
> > In any case, the kernel ignores the value passed in if a valid dtb is
> > passed in.
> 
> I wonder if we should be passing in anything-except-minus-1,
> since if you pass -1 and no DT then the kernel will fail
> silently, whereas if you pass something else and no DT the
> kernel will complain about the mismatch.

Alternately, we can make the kernel always complain about machine type
~0, which is probably safer anyway.

g.