lkml.org 
[lkml]   [2017]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name
From
Date
Hi Frank,

> On Oct 20, 2017, at 00:46 , Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 10/19/17 13:06, Moritz Fischer wrote:
>
> < snip >
>
>> We also have plenty of code that is just not aware of overlays, and
>> assumes certain parts of the tree to stay static.
>
> I would state that somewhat differently. :-) There is very little
> code that is aware of overlays, and most code assumes the device tree
> does not change after early boot.
>
> This is one of the areas where the creation of overlays needs to be
> done with care.
>

Correct. But this is not breaking the kernel.

In general we have the following case where we load overlays (at least
well formed overlays that are not doing stupid things).

1. Activation of a new device. Usually this works since is something that’s
normally done at boot.

2. Deactivation of a device. This might break because the removal paths
of platform device especially are not well tested (or never executed for that
matter).

3. Modification of properties in an already activated device. If the device driver
has not installed a device tree modification hook (as in almost 99% of the devices)
it will do absolutely nothing, since the device tree is parsed only at probe time.
I can argue that for these cases we could have a catch-all hook that displays a
message that nothing happened.

4. Modification of some part of the tree that’s not part of a device driver, perhaps
the aliases or chosen node. This may potentially be harmful or harmless depending on
what has been modified. For instance modifying an already existing alias might cause
internal inconsistency about device naming, while adding a new aliases should be harmless.
This is a matter of policy per board, whether to allow or not.

Are there other cases that are potentially more harmful?

>
>> I ran into that issue when I tried to add thermal zones via an overlay,
>> I've been investigating how to fix the thermal framework to work with
>> overlays since then and have some partially working code.
>> Currently the thermal framework parses the thermal-zones node at boot,
>> and assumes this stays static. This breaks with overlays.
>>
>> I agree we eventually need to fix the parts that break when we use
>> overlays.
>

Regards

— Pantelis

\
 
 \ /
  Last update: 2017-10-22 17:35    [W:0.066 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site