On Thu, 15 May 2014 09:20:24 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Hi Pantelis, > > On Thu, May 15, 2014 at 9:12 AM, Pantelis Antoniou > <pantelis.antoniou@xxxxxxxxxxxx> wrote: > >> We also need to think about kexec. Kexec works by sucking the live tree > >> out of the kernel and creating a .dtb from it to pass to the new kernel. > >> What will the rules be when kexecing? Do all the overlays need to be > >> removed, or does the kernel get the tree with all the overlays applied > >> (in which case none of the overlays can be removed on the other side of > >> kexec). > > > > We can add a sysfs attribute that configures whether overlays are reverted before > > kexec or not. I can't really tell which is the correct option, so let's allow the > > policy up to user-space. > > Kexec'ing into a new kernel doesn't change the hardware, so IMHO the > in-kernel DT should not change. Conceptually though, if overlays are applied then the new kernel has a different tree from the old one. If the overlay is hotpluggable, then after the kexec, the new kernel would no longer be able to unplug the overlay if it uses the current state of the tree instead of pulling the overlays off first. g. -- 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
