On 30 June 2015 at 21:10, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote: > On Tue, Jun 30, 2015 at 12:42 PM, Peter Maydell > <peter.mayd...@linaro.org> wrote: >> On 30 June 2015 at 20:01, Peter Crosthwaite >> <peter.crosthwa...@xilinx.com> wrote: >>> So I actually had my own patches for this one that went in a different >>> direction. The reason is, there are also other devs out there which >>> need post-firmware state setup. The one I an thinking of mainly is the >>> Zynq SLCR setup for non-firmware boots, I.E. the Linux kernel expects >>> firmware to setup devices to some sort of initialized state (mainly >>> turning clocks on). I think this GIC setup falls in the same category. >>> The third use case is the GIC_CPU_IF stuff currently managed by >>> machine code in boot.c that could be outsourced to GIC (in either a >>> similar way to what is done here, or more fully outsourced using my >>> new API). >> >> I'm a bit torn here -- I don't want to make it *too* easy for >> people to add linux-booting specific code to random devices, >> as this will lead to the bootloader code having its tentacles >> everywhere within the tree...
So I thought about this a bit, and I guess that having a general interface is probably better than specifically setting a GIC property. It does need to be called once at arm_kernel_load_notify time, not as a reset hook. I also think it should pass in the arm_boot_info* as a parameter. This would let the GIC do the right thing based on whether we're booting S or NS. Are you planning to respin this patchset, or should I just pull the relevant bits into my series? thanks -- PMM
