From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752163AbaEZVdT (ORCPT ); Mon, 26 May 2014 17:33:19 -0400 Received: from mail-wg0-f51.google.com ([74.125.82.51]:48640 "EHLO mail-wg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751750AbaEZVdO (ORCPT ); Mon, 26 May 2014 17:33:14 -0400 From: Grant Likely Subject: Re: [PATCH v4 2/8] OF: Introduce DT overlay support. To: Pantelis Antoniou Cc: Geert Uytterhoeven , Rob Herring , Stephen Warren , Matt Porter , Koen Kooi , Alison Chaiken , Dinh Nguyen , Jan Lubbe , Alexander Sverdlin , Michael Stickel , Guenter Roeck , Dirk Behme , Alan Tull , Sascha Hauer , Michael Bohan , Ionut Nicu , Michal Simek , Matt Ranostay , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Pete Popov , Dan Malek , Georgi Vlaev In-Reply-To: References: <1396615441-29630-1-git-send-email-pantelis.antoniou@konsulko.com> <1396615441-29630-3-git-send-email-pantelis.antoniou@konsulko.com> <20140514100856.5198DC4153D@trevor.secretlab.ca> <20140516105814.3EA3FC403C2@trevor.secretlab.ca> <20140520055026.E3A98C412DA@trevor.secretlab.ca> <20140526104824.63F13C42129@trevor.secretlab.ca> <20140526112348.907B7C421A5@trevor.secretlab.ca> Date: Mon, 26 May 2014 22:33:03 +0100 Message-Id: <20140526213303.C1C73C40E11@trevor.secretlab.ca> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 26 May 2014 14:55:37 +0300, Pantelis Antoniou wrote: > Hi Grant, > > On May 26, 2014, at 2:23 PM, Grant Likely wrote: > > > On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven wrote: > >> Hi Grant, > >> > >> On Mon, May 26, 2014 at 12:48 PM, Grant Likely > >> wrote: > >>> On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven wrote: > >>>> On Tue, May 20, 2014 at 7:50 AM, Grant Likely wrote: > >>>>>> Why has the overlay system been designed for plugging and unpluging whole > >>>>>> overlays? > >>>>>> That means the kernel has to remember the full stack, causing issues with > >>>>>> e.g. kexec. > >>>>> > >>>>> Mostly so that drivers don't see any difference in the livetree data > >>>>> structure. It also means that userspace sees a single representation of > >>>>> the hardware at any given time. > >>>> > >>>> Sorry, I don't follow the argument about the "single representation of the > >>>> hardware". > >>> > >>> Er, s/of the hardware/of the tree/. Right now the overlay design > >>> modifies the live tree which at the same time modifies the tree > >>> representation in /sys/firmware/devicetree. If the design was changed to > >>> keep the overlay logically separate, then I would think we want to > >>> expose that information to usespace also. In fact, I think we would need > >>> to for usecases like kexec. > >> > >> OK, so it does modify the real tree, and doesn't keep the actual overlays. > >> > >> I was under the impression the overlay stack was also kept in memory, to allow > >> reversal, so there was a misunderstanding. > >> > >> Hence for kexec, the tree in /sys/firmware/devicetree can just be passed > >> to the new kernel, as that's the current representation of the hardware? > > > > Heeheehee. We're back where we started. The original question is whether > > or not that is a valid approach. If the overlay represents something > > that can be hot plugged/unplugged, then passing it through to the second > > kernel would be the wrong thing to do. If it was a permenant addition, > > then it probably doesn't need to be removed. > > > > We do actually keep the overlay info in memory for the purpose of > > removal exactly so we can support hot unbinding of devices and drivers > > that make use of overlays. > > > > We can support either method. I am not feeling any wiser about which one should be > the default TBH, so what about exporting a property and let the platform > figure out which is more appropriate? 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. g.