Hi

On Wed, Aug 13, 2014 at 11:23 AM, Grant Likely
[off-list ref] wrote:

On Wed, Aug 13, 2014 at 9:49 AM, David Herrmann [off-list ref] wrote:

quoted

On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely
[off-list ref] wrote:

quoted

* the exception is an overlay driver which add new devices to the
kernel. Definitely not the case here.

Why?

The majority of the DT code is based on the assumption of a static
tree. Pantelis has been working on being able to modify it at runtime
with overlays, but he has had to go through a lot of rework because it
is not a trivial task. When you get into modifying the DT, you need to
have a lot more understanding of the side effects to changing the
tree. The DT structure also has a lifecycle that can go beyond the
current lifecycle of the kernel. The kexec tool will extract the
current tree from the kernel, make the appropriate modifications, and
use that to boot the next kernel. Allowing any driver to modify the
tree has side effects beyond just the current kernel.

Ok, fair enough. So we leave the DT untouched. That still allows
calling device_add() / device_del() on platform-devices, right?

In this specific case, it will interact badly with the work Pantelis
is doing to make platform devices work with overlays. Modifying the
status property will cause the associated struct device to get removed
in the middle of probing a driver for that device! That will most
likely cause an oops.

Besides, Luc straight out *said*: "...even though it has no real value
today". In what circumstance is that justification for modifying the
tree?

Sorry, I wasn't clear enough: I'm not arguing in favor of this patch.
I just want to figure out what to do once we implement
hardware-handover for graphics devices on non-x86 (which this series
is kinda preparing for). This patch just reminded me, that we could do
this on a DT level, instead of driver-core level. But I'm fine with
avoiding that, if you warn about complications.

Thanks
David