Messages in this thread | | | Date | Tue, 27 May 2014 02:32:20 +0200 | From | Sebastian Reichel <> | Subject | Re: [PATCH v4 2/8] OF: Introduce DT overlay support. |
| |
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 [unhandled content-type:application/pgp-signature] | |