linux-kernel - Re: [RFC] [PATCH] Device Tree on ARM platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090528030430.GE1464@yookeroo.seuss>
Date:	Thu, 28 May 2009 13:04:30 +1000
From:	David Gibson <david@...son.dropbear.id.au>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	Jon Smirl <jonsmirl@...il.com>,
	Scott Wood <scottwood@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	Timur Tabi <timur@...escale.com>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, May 27, 2009 at 02:54:10PM -0600, Grant Likely wrote:
> On Wed, May 27, 2009 at 2:19 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@...osoft.com> wrote:
> >> One option that has been suggested (more than once) is to make the
> >> adapter code an of_platform_driver which translates the device tree
> >> data and then registers the appropriate platform_devices.  This neatly
> >> solves the problem, but I don't like the overhead involved in
> >> registering 2 struct devices with the kernel for every device node in
> >> the device tree.
> > but simplify the dev and maintaining is also an important goal.
> >
> > Have to duplicated ressource handling via ifdef in every drivers is also an
> > overhead which need to be avoided
> 
> agreed.  I don't have a best of both worlds answer here.

I do.  As intimated other places in this thread, I think the right
approach is to register constructor functions that will be used during
boot to traverse the OF devtree and instantiate platform devices (or
other device types in some cases, e.g. i2c).  The driver will then
bind to the platform device this created.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/