[SLOF] [PATCH slof] fdt: Fix creating new nodes at H_CAS

Segher Boessenkool segher at kernel.crashing.org
Thu Jan 30 11:46:03 AEDT 2020

On Thu, Jan 30, 2020 at 10:09:56AM +1100, Alexey Kardashevskiy wrote:
> On 29/01/2020 22:33, Greg Kurz wrote:
> >> Instead, this changes new nodes creation. At pass#0 when we copy phandles
> >> from the FDT update blob to SLOF, we create new nodes with all
> >> new properties and call "finish-device" only after all properties are
> >> copied to the new nodes. At this point we particularly care about "reg"
> >> as this is the unit address which SLOF parses for us and sets the unit
> >> address in "finish-device"; we could skip other properties for later
> > 
> > "finish-device" only sets the first entry of the "reg" property as a
> > fallback. This will be an issue when we start seeing new nodes with
> > bigger unit values (eg, a new PHB).

finish-device should never change (or create or delete or whatever) any
property.  It should finish up the device node, and that's that.

> > The setting of the unit from "reg" is actually handled by
> > "fdt-unflatten-node" which calls "fdt-reg-unit":
> > 
> >       2dup s" reg" str= IF
> >           2swap 2dup fdt-reg-unit 2swap
> >       THEN
> > 
> > Something similar could be done...
> Huh. Should not we then fix "finish-device"?

This whole unit-address setting thing is an implementation detail in SLOF,
it's an optimisation.  It should be kept pretty much invisible.

> > This doesn't address the case of a hotplug-over-hotplug since the
> > new parent node doesn't have a "decode-unit" method, but at least
> > it covers all cases where the parent node was created at boot time.

If a bus node has no decode-unit, you get problems.  Big problems.


More information about the SLOF mailing list