| Message ID | 20190826034512.9656-1-aik@ozlabs.ru |
|---|---|
| State | Accepted |
| Headers | show |
| Series | fdt: Update phandles after H_CAS | expand |
On 26/08/2019 13:45, Alexey Kardashevskiy wrote: > At the moment SLOF generates phandles except a few exceptions such as > an interrupt controller (XICS/XIVE) and NVLink-related nodes. For these > nodes QEMU generates phandles which SLOF later detects and replaces with > the node addresses (which are phandles in SLOF). > > However we are missing these updates when processing > the ibm,client-architecture-support RTAS call - SLOF calls QEMU with H_CAS oops, it is not an RTAS call, it is a client interface, I'll tweak this in my tree. > to get an update for the device tree, and if that blob contains > phandles, they make it to the final tree unchanged with undefined results. > > This calls fdt-fix-phandles for the H_CAS update blob. > > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> > --- > board-qemu/slof/archsupport.fs | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/board-qemu/slof/archsupport.fs b/board-qemu/slof/archsupport.fs > index a8ace3cc59c4..33ea765c152b 100644 > --- a/board-qemu/slof/archsupport.fs > +++ b/board-qemu/slof/archsupport.fs > @@ -29,6 +29,7 @@ > fdt-check-header > fdt-struct fdt-fix-cas-node > fdt-fix-cas-success NOT > + s" /" find-node fdt-fix-phandles > ELSE > FALSE > THEN >
Hi! On Mon, Aug 26, 2019 at 01:45:12PM +1000, Alexey Kardashevskiy wrote: > @@ -29,6 +29,7 @@ > fdt-check-header > fdt-struct fdt-fix-cas-node > fdt-fix-cas-success NOT > + s" /" find-node fdt-fix-phandles find-node is not a standard name, so you could just use device-tree @ to get this info directly (or the standard name for that, 0 peer , but that is a little bit cryptic ;-) ) Segher
On 26/08/2019 16:26, Segher Boessenkool wrote: > Hi! > > On Mon, Aug 26, 2019 at 01:45:12PM +1000, Alexey Kardashevskiy wrote: >> @@ -29,6 +29,7 @@ >> fdt-check-header >> fdt-struct fdt-fix-cas-node >> fdt-fix-cas-success NOT >> + s" /" find-node fdt-fix-phandles > > find-node is not a standard name, so you could just use device-tree @ > to get this info directly (or the standard name for that, 0 peer , but > that is a little bit cryptic ;-) ) Well, this was a quick cut-n-paste from https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/fdt.fs;h=3e4c1b34b8af2d;hb=HEAD#l456 :) Rather than changing that and this patch, I'll leave it as it for now. I am genuinely impressed by you remembering all these things after many years :)
On Tue, Aug 27, 2019 at 11:32:15AM +1000, Alexey Kardashevskiy wrote: > On 26/08/2019 16:26, Segher Boessenkool wrote: > >On Mon, Aug 26, 2019 at 01:45:12PM +1000, Alexey Kardashevskiy wrote: > >>@@ -29,6 +29,7 @@ > >> fdt-check-header > >> fdt-struct fdt-fix-cas-node > >> fdt-fix-cas-success NOT > >>+ s" /" find-node fdt-fix-phandles > > > >find-node is not a standard name, so you could just use device-tree @ > >to get this info directly (or the standard name for that, 0 peer , but > >that is a little bit cryptic ;-) ) > Well, this was a quick cut-n-paste from > https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/fdt.fs;h=3e4c1b34b8af2d;hb=HEAD#l456 > :) Yeah, it was just a comment. > Rather than changing that and this patch, I'll leave it as it for now. I > am genuinely impressed by you remembering all these things after many > years :) Everything *-node is SLOF-specific, don't be too impressed ;-) Segher
On Mon, 26 Aug 2019 13:45:12 +1000 Alexey Kardashevskiy <aik@ozlabs.ru> wrote: > At the moment SLOF generates phandles except a few exceptions such as > an interrupt controller (XICS/XIVE) and NVLink-related nodes. For these > nodes QEMU generates phandles which SLOF later detects and replaces with > the node addresses (which are phandles in SLOF). > > However we are missing these updates when processing > the ibm,client-architecture-support RTAS call - SLOF calls QEMU with H_CAS > to get an update for the device tree, and if that blob contains > phandles, they make it to the final tree unchanged with undefined results. > > This calls fdt-fix-phandles for the H_CAS update blob. > > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> > --- Heh I was thinking something like that would be needed if we try to get rid of CAS reboot :) Reviewed-by: Greg Kurz <groug@kaod.org> > board-qemu/slof/archsupport.fs | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/board-qemu/slof/archsupport.fs b/board-qemu/slof/archsupport.fs > index a8ace3cc59c4..33ea765c152b 100644 > --- a/board-qemu/slof/archsupport.fs > +++ b/board-qemu/slof/archsupport.fs > @@ -29,6 +29,7 @@ > fdt-check-header > fdt-struct fdt-fix-cas-node > fdt-fix-cas-success NOT > + s" /" find-node fdt-fix-phandles > ELSE > FALSE > THEN
diff --git a/board-qemu/slof/archsupport.fs b/board-qemu/slof/archsupport.fs index a8ace3cc59c4..33ea765c152b 100644 --- a/board-qemu/slof/archsupport.fs +++ b/board-qemu/slof/archsupport.fs @@ -29,6 +29,7 @@ fdt-check-header fdt-struct fdt-fix-cas-node fdt-fix-cas-success NOT + s" /" find-node fdt-fix-phandles ELSE FALSE THEN
At the moment SLOF generates phandles except a few exceptions such as an interrupt controller (XICS/XIVE) and NVLink-related nodes. For these nodes QEMU generates phandles which SLOF later detects and replaces with the node addresses (which are phandles in SLOF). However we are missing these updates when processing the ibm,client-architecture-support RTAS call - SLOF calls QEMU with H_CAS to get an update for the device tree, and if that blob contains phandles, they make it to the final tree unchanged with undefined results. This calls fdt-fix-phandles for the H_CAS update blob. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> --- board-qemu/slof/archsupport.fs | 1 + 1 file changed, 1 insertion(+)