From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752555AbaEZPO0 (ORCPT ); Mon, 26 May 2014 11:14:26 -0400 Received: from mail.active-venture.com ([67.228.131.205]:59351 "EHLO mail.active-venture.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751549AbaEZPOY (ORCPT ); Mon, 26 May 2014 11:14:24 -0400 X-Originating-IP: 108.223.40.66 Message-ID: <53835A40.8050902@roeck-us.net> Date: Mon, 26 May 2014 08:14:08 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sebastian Reichel , Pantelis Antoniou CC: Grant Likely , Geert Uytterhoeven , Rob Herring , Stephen Warren , Matt Porter , Koen Kooi , Alison Chaiken , Dinh Nguyen , Jan Lubbe , Alexander Sverdlin , Michael Stickel , 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 Subject: Re: [PATCH v4 2/8] OF: Introduce DT overlay support. References: <20140516105814.3EA3FC403C2@trevor.secretlab.ca> <20140520055026.E3A98C412DA@trevor.secretlab.ca> <20140526104824.63F13C42129@trevor.secretlab.ca> <20140526112348.907B7C421A5@trevor.secretlab.ca> <20140526150942.GA26787@earth.universe> In-Reply-To: <20140526150942.GA26787@earth.universe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/26/2014 08:09 AM, Sebastian Reichel wrote: > Hi, > > On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote: >> On May 26, 2014, at 2:23 PM, Grant Likely wrote: >>> On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven wrote: >>> 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? > > What about supporting "negative" overlays (so an overlay, that > removes DT entries)? That way one could reverse apply an overlay. > All the dependency stuff would basically be the users problem. The > kernel only checks if it can apply an overlay (and return some error > code if it can't). This this code is needed anyway to check the > input from userspace. > Does that mean that I would need to describe such a negative overlay for each overlay to be able to get it removed ? This would introduce an endless source of problems with bad "reverse" overlay descriptions. Sure, that would "be the users problem", but I don't think that would make it better. Guenter