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 <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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
