From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Nzae1-0004yZ-HK
	for qemu-devel@nongnu.org; Wed, 07 Apr 2010 15:10:33 -0400
Received: from [140.186.70.92] (port=40313 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Nzae0-0004xy-7M
	for qemu-devel@nongnu.org; Wed, 07 Apr 2010 15:10:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <blauwirbel@gmail.com>) id 1Nzady-0000aq-IN
	for qemu-devel@nongnu.org; Wed, 07 Apr 2010 15:10:32 -0400
Received: from mail-pz0-f204.google.com ([209.85.222.204]:35687)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <blauwirbel@gmail.com>) id 1Nzady-0000aY-CX
	for qemu-devel@nongnu.org; Wed, 07 Apr 2010 15:10:30 -0400
Received: by pzk42 with SMTP id 42so810790pzk.4
	for <qemu-devel@nongnu.org>; Wed, 07 Apr 2010 12:10:29 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20100407040129.20274.44284.stgit@angua>
References: <20100407040129.20274.44284.stgit@angua>
Date: Wed, 7 Apr 2010 22:10:28 +0300
Message-ID: <k2kf43fc5581004071210v810be251nf77b7ab469004e5c@mail.gmail.com>
Subject: Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from
	qdevs
From: Blue Swirl <blauwirbel@gmail.com>
Content-Type: text/plain; charset=UTF-8
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: Grant Likely <grant.likely@secretlab.ca>
Cc: devicetree-discuss@lists.ozlabs.org, qemu-devel@nongnu.org, jeremy.kerr@canonical.com

On 4/7/10, Grant Likely <grant.likely@secretlab.ca> wrote:
> Hi everyone,
>
>  This is an experimental set of patches for populating the flattened
>  device tree (fdt) data from the actual set of qdevs in the platform.
>  I'm not expecting this to get merged anytime soon, but I wanted to get
>  it out there to solicit comments.  My target for this is testing
>  device tree support on ARM.
>
>  The approach is by no means final, and there are still a number of
>  details to work out, but I've got it working well with the versatile
>  platform and I've got the kernel using fdt data to bind against the
>  smc91x device driver.  I'll be posting my associated kernel patches
>  real-soon-now.

It looks like the hook is only used to add some additional properties.
I think a data driven approach (fields in qdev structure) would be
simpler because the handling code would be only in qdev instead of all
devices.

Something like:
static SysBusDeviceInfo smc91c111_info = {
    .init = smc91c111_init1,
    .qdev.name  = "smc91c111",
    .qdev.size  = sizeof(smc91c111_state),
    .qdev.props = (Property[]) {
        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
        DEFINE_PROP_END_OF_LIST(),
    },
    .qdev.fdt_props = (FDTProperty[]) {
        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
conf.macaddr),
        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
        DEFINE_FDT_PROP_END_OF_LIST(),
    }
};

A separate question is whether the properties should be visible to
user, for example shown by "info qdev". If yes, then the FDT
properties should be a special case of qdev properties:
    .qdev.props = (Property[]) {
        DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
        DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
conf.macaddr),
        DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
        DEFINE_PROP_END_OF_LIST(),
    }