From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MEkR3-0005bA-Av
	for qemu-devel@nongnu.org; Thu, 11 Jun 2009 09:35:17 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MEkQy-0005Z5-Lk
	for qemu-devel@nongnu.org; Thu, 11 Jun 2009 09:35:16 -0400
Received: from [199.232.76.173] (port=47882 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MEkQy-0005Yt-FC
	for qemu-devel@nongnu.org; Thu, 11 Jun 2009 09:35:12 -0400
Received: from mx20.gnu.org ([199.232.41.8]:41064)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <kraxel@redhat.com>) id 1MEkQy-0002VM-6B
	for qemu-devel@nongnu.org; Thu, 11 Jun 2009 09:35:12 -0400
Received: from mx2.redhat.com ([66.187.237.31])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MEkQv-00024c-6t
	for qemu-devel@nongnu.org; Thu, 11 Jun 2009 09:35:09 -0400
Message-ID: <4A31078C.9000403@redhat.com>
Date: Thu, 11 Jun 2009 15:33:00 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 2/4] Add device tree machine
References: <20090610173803.4674.82538.stgit@wren.home>
	<20090610173821.4674.58171.stgit@wren.home>
In-Reply-To: <20090610173821.4674.58171.stgit@wren.home>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

A few more comments ...

> +static void dt_add_props(DeviceState *dev, void *dt, int offset)
> +{

Where do device properties come from?  Only the fdt tree?  If so, do we 
need the property lists in the first place?  We could get them directly 
from the fdt tree instead.

> +static const DevicePropList i2c_bus_props[] = {
> +      {.name = "address", .type = PROP_TYPE_INT},
> +      {.name = NULL}
> +};

That could go into BusInfo as well.

cheers,
   Gerd