Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

[Sebastian Reichel]

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