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 <geert@xxxxxxxxxxxxxx> 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. As a result the overlay handling would basically have the same behaviour as diff and patch :) P.S.: Sorry if this has already been suggested. I have only read mails from PATCHv4. -- Sebastian
Attachment:
signature.asc
Description: Digital signature
