Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

[Sebastian Reichel <sre@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]

Hi,

On Mon, May 26, 2014 at 08:14:08AM -0700, Guenter Roeck wrote:
> On 05/26/2014 08:09 AM, Sebastian Reichel wrote:
> >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@linux-m68k.org> 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.

I was thinking about supporting something like "patch --reverse". So
you can try to undo the overlay by reverse applying it and you can
do it in arbitrary order.

Note: The dependency check must be done for all overlays coming from
userspace, so that's not a problem __here__. The reverse method can
"simply" reverse the overlay patch and apply it like a normal
overlay from userspace (and thus using the same dependency checks).

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]