On Mon, 26 May 2014 16:42:44 -0700, Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > On 05/26/2014 03:36 PM, Sebastian Reichel wrote: > > Hi, > > > > On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote: > >> After thinking about it more, I think it is very likely that removing > >> all the overlays is the correct thing to do in the kexec use-case. When > >> kexec-ing, it makes sense that we'd want the exact same behaviour from > >> the kexec'ed kernel. That means we want the device drivers to do the > >> same thing including loading whatever overlays they depend on. > >> > >> If the flattened tree was left applied, then the behaviour becomes > >> different. > >> > >> I say always remove the overlays unless explicitly told not to, but I'm > >> struggling to come up with use cases where keeping them applied is > >> desirable. > > > > I would assume, that I want them applied in most cases. DT describes > > the hardware. If I kexec into a new kernel I change software, not > > hardware. > > > > Maybe I'm missing the main purpose of the feature. I currently see > > two useful usecases for DT overlays: > > > > 1. The dtb the kernel is booted with cannot be changed for some > > reason, but the board has additional hardware attached (e.g. > > the user added a sensor on the i2c bus) > > 2. The hardware is changed on the fly (e.g. the user flashed the > > FPGA part of a zynq processor), sensors on i2c bus, ... > > > > In both cases the kernel should be booted with the additional > > overlay information IMHO. Though for the second case it should > > be possible to remove the "programmed" hardware information > > somehow. > > > > 3. Some hot-plug device or card is inserted or removed. > > I would argue that the kernel should _not_ be booted with the overlay in place. > Otherwise the code handling overlays would have to have special handling > for the restart case, which is much more complex than just to re-insert > the overlay when it is determined that the device or card is still there. Exactly. 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
