Hi Guenter, On May 27, 2014, at 6:21 PM, Guenter Roeck wrote: > On Tue, May 27, 2014 at 03:24:35PM +0300, Pantelis Antoniou wrote: >> Hi Grant, >> >> On May 27, 2014, at 3:12 PM, Grant Likely wrote: >> >>> 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. >>> >> >> Looks like we are levitating to the 'remove overlays on kexec' approach. >> Is that correct? >> > > Let's just assume for a minute that this is not the case, and that loaded > overlays are passed on. > > This would be an interesting challenge for the overlay manager, as it would > have to handle a number of startup conditions. After all, it can not take > it as granted that the hardware state did not change after it was stopped > in the old kernel, and before it was started in the new kernel. > - overlay loaded, but hardware/device no longer present > -> unload overlay > - overlay loaded, but different hardware present > -> unload old overlay, load new one > - overlay not loaded, hardware present > -> load overlay > - overlay loaded and matches hardware > -> do nothing > > In comparison, its task would be quite straightforward if loaded overlays > are not passed on to the new kernel. > - If hardware is present, load overlay > Yeah, exactly. The only case where having the applied overlays present on the kexec-ed kernel is either some kind of virtualization environment, or an fpga that takes an awful lot amount of time to re-initializa. > Ultimately, I seem to be missing something, as I don't really see the benefit > of passing on the loaded overlay(s) to the new kernel. Activation time, maybe, > for the most common case (overlay loaded and matches hardware) ? > > Concern though is the other cases, with a mismatch between HW and loaded > overlays. I am not sure if it is even possible to ensure that there are > no race conditions if the devicetree is outdated at system startup. Sure, > that is unlikely to happen in 'normal' operating conditions, but that only > means that it _will_ happen a few hours after the first customer starts > playing with the system. > I concur. Accidents will happen, and if it's not a tightly controlled system breakage is guaranteed. > Guenter Regards -- Pantelis > -- > 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 -- 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
