From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pantelis Antoniou Subject: Re: [PATCH v4 2/8] OF: Introduce DT overlay support. Date: Mon, 26 May 2014 14:55:37 +0300 Message-ID: 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> Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <20140526112348.907B7C421A5@trevor.secretlab.ca> Sender: linux-kernel-owner@vger.kernel.org To: Grant Likely 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 List-Id: devicetree@vger.kernel.org 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? > g. > Regards -- Pantelis > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html