Hello,
On 08/09/16 16:17, Rob Herring wrote:
>> The comment to OF_POPULATED_BUS says "of_platform_populate recursed to children
>> > of this node". Consider the following structure:
>> >
>> > ocp {
>> > compatible = "simple-bus";
>> > ranges;
>> > ...
>> > l4_wkup: l4_wkup@44c00000 {
>> > compatible = "ti,am3-l4-wkup", "simple-bus";
>> > ranges = <0 0x44c00000 0x280000>;
>> > ...
>> > wkup_m3: wkup_m3@100000 {
>> > compatible = "ti,am3352-wkup-m3";
>> > ...
>> > }
>> > }
>> > }
>> >
>> > If one DT overlay adds "ocp" node without children then of_platform_notify()
>> > creates a platform device, but doesn't set OF_POPULATED_BUS. If second overlay
>> > tries to populate children of "ocp" node, corresponding platform devices are
>> > not instantiated because of check for OF_POPULATED_BUS flag. If the above
>> > example structure is built of several overlays, of_platform_populate() is not
>> > involved here at all, so maybe OF_POPULATED_BUS requirement is wrong.
> Your example seems a bit made up. While you can craft base DTs and
> overlays with any random split between them, I don't necessarily think
> we want to support that. There will likely be cases which we say can
> only be applied early in boot or we limit which nodes can be overlay
> targets for overlays applied from userspace.
Yes, I had to construct an example out of the well-known Beaglebone DT pieces,
the real use case will only confuse the public.
In general I don't understand why my example is so bizarre, it basically shows, you
cannot apply an overlay above overlay: the devices will not be registered and actually
because of the bogus check. Imagine the well known Beagle: you can construct a bone with
whatever SPI/I2C bus controller. On top of it you can sandwich a board with I2C-driven
GPIO extenders. Is it absolute unrealistic?
There is full support of multilevel overlays. And just one bug preventing it from working
properly. Do we really want it?
--
Best regards,
Alexander Sverdlin.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
