Hi On Wed, Aug 13, 2014 at 11:23 AM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > On Wed, Aug 13, 2014 at 9:49 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: >> On Wed, Aug 13, 2014 at 10:40 AM, Grant Likely >> <grant.likely@xxxxxxxxxxxx> wrote: >>> * 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
