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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> Hi Grant,
> 
> On Mon, May 26, 2014 at 12:48 PM, Grant Likely
> <grant.likely@xxxxxxxxxxxx> wrote:
> > On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> >> On Tue, May 20, 2014 at 7:50 AM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
> >> >> Why has the overlay system been designed for plugging and unpluging whole
> >> >> overlays?
> >> >> That means the kernel has to remember the full stack, causing issues with
> >> >> e.g. kexec.
> >> >
> >> > Mostly so that drivers don't see any difference in the livetree data
> >> > structure. It also means that userspace sees a single representation of
> >> > the hardware at any given time.
> >>
> >> Sorry, I don't follow the argument about the "single representation of the
> >> hardware".
> >
> > Er, s/of the hardware/of the tree/. Right now the overlay design
> > modifies the live tree which at the same time modifies the tree
> > representation in /sys/firmware/devicetree. If the design was changed to
> > keep the overlay logically separate, then I would think we want to
> > expose that information to usespace also. In fact, I think we would need
> > to for usecases like kexec.
> 
> OK, so it does modify the real tree, and doesn't keep the actual overlays.
> 
> I was under the impression the overlay stack was also kept in memory, to allow
> reversal, so there was a misunderstanding.
> 
> Hence for kexec, the tree in /sys/firmware/devicetree can just be passed
> to the new kernel, as that's the current representation of the hardware?

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.

g.

--
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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux