From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NzcK0-00020z-8a for qemu-devel@nongnu.org; Wed, 07 Apr 2010 16:58:00 -0400 Received: from [140.186.70.92] (port=45257 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NzcJy-00020n-Qt for qemu-devel@nongnu.org; Wed, 07 Apr 2010 16:57:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NzcJw-0002X0-Uo for qemu-devel@nongnu.org; Wed, 07 Apr 2010 16:57:58 -0400 Received: from mail-yw0-f198.google.com ([209.85.211.198]:37662) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NzcJw-0002Ws-Qy for qemu-devel@nongnu.org; Wed, 07 Apr 2010 16:57:56 -0400 Received: by ywh36 with SMTP id 36so689974ywh.4 for ; Wed, 07 Apr 2010 13:57:55 -0700 (PDT) MIME-Version: 1.0 Sender: glikely@secretlab.ca In-Reply-To: References: <20100407040129.20274.44284.stgit@angua> From: Grant Likely Date: Wed, 7 Apr 2010 14:57:35 -0600 Message-ID: Subject: Re: [Qemu-devel] [RFC PATCH 0/7] QEMU patches to generate FDT from qdevs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: devicetree-discuss@lists.ozlabs.org, qemu-devel@nongnu.org, jeremy.kerr@canonical.com Thanks for the comments. Replies below... On Wed, Apr 7, 2010 at 1:10 PM, Blue Swirl wrote: > On 4/7/10, Grant Likely wrote: >> Hi everyone, >> >> =A0This is an experimental set of patches for populating the flattened >> =A0device tree (fdt) data from the actual set of qdevs in the platform. >> =A0I'm not expecting this to get merged anytime soon, but I wanted to ge= t >> =A0it out there to solicit comments. =A0My target for this is testing >> =A0device tree support on ARM. >> >> =A0The approach is by no means final, and there are still a number of >> =A0details to work out, but I've got it working well with the versatile >> =A0platform and I've got the kernel using fdt data to bind against the >> =A0smc91x device driver. =A0I'll be posting my associated kernel patches >> =A0real-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. Hmmm, maybe. I don't really have a good answer yet as I'm still experimenting. It is possible that I'll need more complex behaviour as I add new kinds of devices or for handling different bus types. For example, right now I've got code to change the node name for mmio devices, and that cannot be filled in until the register base is defined and the best name format may be different for different busses/devices. I'm not familiar enough with qemu to know how best to handle this with properties. > Something like: > static SysBusDeviceInfo smc91c111_info =3D { > =A0 =A0.init =3D smc91c111_init1, > =A0 =A0.qdev.name =A0=3D "smc91c111", > =A0 =A0.qdev.size =A0=3D sizeof(smc91c111_state), > =A0 =A0.qdev.props =3D (Property[]) { > =A0 =A0 =A0 =A0DEFINE_NIC_PROPERTIES(smc91c111_state, conf), > =A0 =A0 =A0 =A0DEFINE_PROP_END_OF_LIST(), > =A0 =A0}, > =A0 =A0.qdev.fdt_props =3D (FDTProperty[]) { > =A0 =A0 =A0 =A0DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_stat= e, > conf.macaddr), > =A0 =A0 =A0 =A0DEFINE_FDT_PROP_STR("compatible", "smc,91c111"), > =A0 =A0 =A0 =A0DEFINE_FDT_PROP_END_OF_LIST(), > =A0 =A0} > }; > > 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: > =A0 =A0.qdev.props =3D (Property[]) { > =A0 =A0 =A0 =A0DEFINE_NIC_PROPERTIES(smc91c111_state, conf), > =A0 =A0 =A0 =A0DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_stat= e, > conf.macaddr), > =A0 =A0 =A0 =A0DEFINE_FDT_PROP_STR("compatible", "smc,91c111"), > =A0 =A0 =A0 =A0DEFINE_PROP_END_OF_LIST(), > =A0 =A0} It would certainly be useful to see the device node(s) associated with a qd= ev. g.