Message-ID: <20140527182201.GA2439@roeck-us.net>
Date:	Tue, 27 May 2014 11:22:01 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Sebastian Reichel <sre@...nel.org>,
	Rob Herring <robherring2@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Matt Porter <matt.porter@...aro.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Alison Chaiken <Alison_Chaiken@...tor.com>,
	Dinh Nguyen <dinh.linux@...il.com>,
	Jan Lubbe <jluebbe@...net.de>,
	Alexander Sverdlin <alexander.sverdlin@....com>,
	Michael Stickel <ms@...able.de>,
	Dirk Behme <dirk.behme@...il.com>,
	Alan Tull <delicious.quinoa@...il.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Michael Bohan <mbohan@...eaurora.org>,
	Ionut Nicu <ioan.nicu.ext@....com>,
	Michal Simek <monstr@...str.eu>,
	Matt Ranostay <mranostay@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Pete Popov <pete.popov@...sulko.com>,
	Dan Malek <dan.malek@...sulko.com>,
	Georgi Vlaev <georgi.vlaev@...sulko.com>
Subject: Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

Hi Geert,

On Tue, May 27, 2014 at 07:52:57PM +0200, Geert Uytterhoeven wrote:
> Hi Günther,
> 
> On Tue, May 27, 2014 at 5:21 PM, Guenter Roeck <linux@...ck-us.net> wrote:
> > On Tue, May 27, 2014 at 03:24:35PM +0300, Pantelis Antoniou wrote:
> >> On May 27, 2014, at 3:12 PM, Grant Likely wrote:
> >> > On Mon, 26 May 2014 16:42:44 -0700, Guenter Roeck <linux@...ck-us.net> wrote:
> >> >> On 05/26/2014 03:36 PM, Sebastian Reichel wrote:
> >> >>> On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote:
> >> >>>> After thinking about it more, I think it is very likely that removing
> >> >>>> all the overlays is the correct thing to do in the kexec use-case. When
> >> >>>> kexec-ing, it makes sense that we'd want the exact same behaviour from
> >> >>>> the kexec'ed kernel. That means we want the device drivers to do the
> >> >>>> same thing including loading whatever overlays they depend on.
> >> >>>>
> >> >>>> If the flattened tree was left applied, then the behaviour becomes
> >> >>>> different.
> >> >>>>
> >> >>>> I say always remove the overlays unless explicitly told not to, but I'm
> >> >>>> struggling to come up with use cases where keeping them applied is
> >> >>>> desirable.
> >> >>>
> >> >>> I would assume, that I want them applied in most cases. DT describes
> >> >>> the hardware. If I kexec into a new kernel I change software, not
> >> >>> hardware.
> >> >>>
> >> >>> Maybe I'm missing the main purpose of the feature. I currently see
> >> >>> two useful usecases for DT overlays:
> >> >>>
> >> >>> 1. The dtb the kernel is booted with cannot be changed for some
> >> >>>    reason, but the board has additional hardware attached (e.g.
> >> >>>    the user added a sensor on the i2c bus)
> >> >>> 2. The hardware is changed on the fly (e.g. the user flashed the
> >> >>>    FPGA part of a zynq processor), sensors on i2c bus, ...
> >> >>>
> >> >>> In both cases the kernel should be booted with the additional
> >> >>> overlay information IMHO. Though for the second case it should
> >> >>> be possible to remove the "programmed" hardware information
> >> >>> somehow.
> >> >>>
> >> >>
> >> >> 3. Some hot-plug device or card is inserted or removed.
> >> >>
> >> >> I would argue that the kernel should _not_ be booted with the overlay in place.
> >> >> Otherwise the code handling overlays would have to have special handling
> >> >> for the restart case, which is much more complex than just to re-insert
> >> >> the overlay when it is determined that the device or card is still there.
> >> >
> >> > Exactly.
> >> >
> >>
> >> Looks like we are levitating to the 'remove overlays on kexec' approach.
> >> Is that correct?
> >>
> >
> > Let's just assume for a minute that this is not the case, and that loaded
> > overlays are passed on.
> >
> > This would be an interesting challenge for the overlay manager, as it would
> > have to handle a number of startup conditions. After all, it can not take
> > it as granted that the hardware state did not change after it was stopped
> > in the old kernel, and before it was started in the new kernel.
> > - overlay loaded, but hardware/device no longer present
> >   -> unload overlay
> > - overlay loaded, but different hardware present
> >   -> unload old overlay, load new one
> > - overlay not loaded, hardware present
> >   -> load overlay
> > - overlay loaded and matches hardware
> >   -> do nothing
> >
> > In comparison, its task would be quite straightforward if loaded overlays
> > are not passed on to the new kernel.
> > - If hardware is present, load overlay
> >
> > Ultimately, I seem to be missing something, as I don't really see the benefit
> > of passing on the loaded overlay(s) to the new kernel. Activation time, maybe,
> > for the most common case (overlay loaded and matches hardware) ?
> 
> All of the above assume you're using a system with overlays and an overlay
> manager. I.e. you have add-on devices together with an overlay DT.
> One way to handle this is via auto-detection of capes, that identify themselves,
> so the overlay manager knows which overlay to load.
> 
Possibly auto-detected (and in our case that is so), but not necessarily.
A user space overlay manager, which keeps state in user space, would be possible
as well.

> I'm trying to look at it in a more generic way: you add hardware which is not
> in the DT, so the DT must be modified (in some way or another) to match the
> hardware.
> 
> If you run kexec, the added hardware is still there. In the absence of a system
> with auto-detection of capes, the newly booted kernel cannot know that
> hardware has been added, compared to a pristine system. If it's in the
> DT passed through kexec, everything will work.
> 
Yes, but only for that case. You'd still have the problem that you'll need 
to keep the state somewhere to be able to remove the pre-loaded overlay(s) later
on. If you don't have hardware auto-detection, I would assume that to be in user
space. No matter if the system auto-detects hardware or not, the same mechanism
could be used: If, on startup, the hardware status (no matter if kept in some
file or auto-detected) indicates that an overlay should be loaded, load it.

If, for some reason, the overlay manager can not auto-detect hardware but keeps
state in the kernel, it may make sense to have that state passed to the new kernel.
However, that should be part of the overlay manager implementation, and not be
dictated by the core overlay mechanism.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists