On Mon, May 26, 2014 at 04:42:44PM -0700, Guenter Roeck wrote: > On 05/26/2014 03:36 PM, Sebastian Reichel wrote: > >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. Can you give a more specific example? I guess most hot-plug devices are connected to busses, which are not described via DT, but support auto-identification (USB, PCI, ...) > I would argue that the kernel should _not_ be booted with the > overlay in place. well the device is still attached to the system when you kexec into the new kernel, isn't it? > 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. I assume, that the kernel cannot auto-detect the attached hardware. Otherwise we don't need the DT entries, but can simply scan the bus. So the restart case (or restart + kexec case if kexec behaves like a restart) means, that userspace needs to provide the information about device existence. Removing the overlay is like dropping information supplied from the user. Not something, which should be done carelessly. -- Sebastian
Attachment:
signature.asc
Description: Digital signature
