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

[Pantelis Antoniou]

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?

> g.
> 

Regards

-- Pantelis


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/