linux-kernel - Re: [RFC] (early draft) dt: Linux dt usage model documentation

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: <20110615071336.GC31712@S2100-06.ap.freescale.net>
Date:	Wed, 15 Jun 2011 15:13:37 +0800
From:	Shawn Guo <shawn.guo@...escale.com>
To:	Grant Likely <grant.likely@...retlab.ca>
CC:	<devicetree-discuss@...ts.ozlabs.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	<linaro-dev@...ts.linaro.org>, <linux-kernel@...r.kernel.org>,
	<linux-doc@...r.kernel.org>
Subject: Re: [RFC] (early draft) dt: Linux dt usage model documentation

Hi Grant,

On Mon, Jun 13, 2011 at 07:32:15AM -0600, Grant Likely wrote:
[...]
> +Linux board support code calls of_platform_populate(NULL, NULL, NULL)
> +to kick of discovery of devices at the root of the tree.  The
> +parameters are all NULL because when starting from the root of the
> +tree, there is no need to provide a starting node (the first NULL), a
> +parent struct device (the last NULL), and we're not using a match
> +table (yet).  For a board that only needs to register devices,
> +.init_machine() can be completely empty except for the
> +of_platform_populate() call.
> +
> +In the Tegra example, this accounts for the /soc and /sound nodes, but
> +what about the children of the soc node?  Shouldn't they be registered
> +as platform devices too?  For Linux DT support, the generic behaviour
> +is for child devices to be registered by the parent's device driver at
> +driver .probe() time.  So, an i2c bus device driver will register a
> +i2c_client for each child node, an spi bus driver will register
> +it's spi_device children, and similarly for other bus_types.
> +According to that model, a driver could be written that binds to the
> +soc node and simply registers platform_devices for each of it's
> +children.  The board support code would allocate and register an soc
> +device, an soc device driver would bind to the soc device, and
> +register platform_devices for /soc/interrupt-controller, /soc/serial,
> +/soc/i2s, and /soc/i2c in it's .probe() hook.  Easy, right?  Although

I do not quite understand what the "soc device driver" is here.
Looking at the devicetree/test code, I do not find this driver and
its .probe() hook.  Instead, of_platform_bus_create will create
platform_device for the provided device_node, and also recursively
create devices for all the child nodes, no?

> +it is a lot of mucking about for just registering platform devices.
> +

-- 
Regards,
Shawn

--
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/