From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752318AbdJTIGf (ORCPT ); Fri, 20 Oct 2017 04:06:35 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:44494 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751989AbdJTIG2 (ORCPT ); Fri, 20 Oct 2017 04:06:28 -0400 X-Google-Smtp-Source: ABhQp+TDmvhe2Z2VokW+LdG64pxB3jMkjTIZd/TLZySduhvyAcwncI3exTJuC3V7nndIy0nG32DOHg== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH v2 5/5] of/fdt: only store the device node basename in full_name From: Pantelis Antoniou In-Reply-To: <59E91D4D.8000200@gmail.com> Date: Fri, 20 Oct 2017 11:06:23 +0300 Cc: Moritz Fischer , Rob Herring , Alan Tull , "devicetree@vger.kernel.org" , Michael Ellerman , linuxppc-dev , linux-kernel , Benjamin Herrenschmidt , Paul Mackerras , David Laight , linux-fpga@vger.kernel.org Message-Id: <331B5EB4-9C97-4B2C-9B54-BF648F309A50@konsulko.com> References: <20170821151651.25096-1-robh@kernel.org> <20170821151651.25096-6-robh@kernel.org> <59E69786.2030406@gmail.com> <1508341985.25643.12.camel@hp800z> <4393AFA4-620F-4C21-995D-A9806DAE1990@konsulko.com> <20171019200615.GA10743@tyrael.ni.corp.natinst.com> <59E91D4D.8000200@gmail.com> To: Frank Rowand X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v9K878uf021568 Hi Frank, > On Oct 20, 2017, at 00:46 , Frank Rowand 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