From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Subject: Re: [PATCH v4 2/8] OF: Introduce DT overlay support. Date: Mon, 26 May 2014 08:14:08 -0700 Message-ID: <53835A40.8050902@roeck-us.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140526150942.GA26787-SfvFxonMDyemK9LvCR3Hrw@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Pete Popov , Dan Malek List-Id: devicetree@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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html