Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread Stephen Boyd
Quoting James Morse (2019-05-16 10:34:16) > Hi! > > On 16/05/2019 17:48, Hsin-Yi Wang wrote: > > On Thu, May 16, 2019 at 11:32 PM Rob Herring wrote: > >> Doesn't kexec operate on a copy because it already does modifications. > > It does! > > > This patch is to assist "[PATCH v3 3/3] fdt: add

Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread James Morse
Hi! On 16/05/2019 17:48, Hsin-Yi Wang wrote: > On Thu, May 16, 2019 at 11:32 PM Rob Herring wrote: >> Doesn't kexec operate on a copy because it already does modifications. It does! > This patch is to assist "[PATCH v3 3/3] fdt: add support for rng-seed" >

Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread Hsin-Yi Wang
On Thu, May 16, 2019 at 11:32 PM Rob Herring wrote: > Doesn't kexec operate on a copy because it already does modifications. > Hi Rob, This patch is to assist "[PATCH v3 3/3] fdt: add support for rng-seed" (https://lkml.org/lkml/2019/5/16/257). I thought that by default second kernel would use

Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread Rob Herring
On Thu, May 16, 2019 at 9:51 AM Hsin-Yi Wang wrote: > > On Thu, May 16, 2019 at 10:37 PM Rob Herring wrote: > > > > > Why not just map the FDT R/W at the start and change it to RO just > > before calling unflatten_device_tree? Then all the FDT scanning > > functions or any future fixups we need

Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread Rob Herring
On Thu, May 16, 2019 at 9:43 AM Mark Rutland wrote: > > On Thu, May 16, 2019 at 09:37:05AM -0500, Rob Herring wrote: > > On Thu, May 16, 2019 at 5:28 AM Hsin-Yi Wang wrote: > > > > > > Basically does similar things like __fixmap_remap_fdt(). It's supposed > > > to be called after

Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread Hsin-Yi Wang
On Thu, May 16, 2019 at 10:37 PM Rob Herring wrote: > > Why not just map the FDT R/W at the start and change it to RO just > before calling unflatten_device_tree? Then all the FDT scanning > functions or any future fixups we need can just assume R/W. That is > essentially what Stephen suggested.

Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread Mark Rutland
On Thu, May 16, 2019 at 09:37:05AM -0500, Rob Herring wrote: > On Thu, May 16, 2019 at 5:28 AM Hsin-Yi Wang wrote: > > > > Basically does similar things like __fixmap_remap_fdt(). It's supposed > > to be called after fixmap_remap_fdt() is called at least once, so region > > checking can be

Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread Ard Biesheuvel
On Thu, 16 May 2019 at 16:37, Rob Herring wrote: > > On Thu, May 16, 2019 at 5:28 AM Hsin-Yi Wang wrote: > > > > Basically does similar things like __fixmap_remap_fdt(). It's supposed > > to be called after fixmap_remap_fdt() is called at least once, so region > > checking can be skipped. Since

Re: [PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread Rob Herring
On Thu, May 16, 2019 at 5:28 AM Hsin-Yi Wang wrote: > > Basically does similar things like __fixmap_remap_fdt(). It's supposed > to be called after fixmap_remap_fdt() is called at least once, so region > checking can be skipped. Since it needs to know dt physical address, make > a copy of the

[PATCH v3 2/3] arm64: implement update_fdt_pgprot()

2019-05-16 Thread Hsin-Yi Wang
Basically does similar things like __fixmap_remap_fdt(). It's supposed to be called after fixmap_remap_fdt() is called at least once, so region checking can be skipped. Since it needs to know dt physical address, make a copy of the value of __fdt_pointer. Signed-off-by: Hsin-Yi Wang ---