| Message ID | afce097ece19838f33b2249e314804734a9f6e8a.1425884424.git.jan.kiszka@siemens.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
On Mon, Mar 09, 2015 at 08:00:11AM +0100, Jan Kiszka wrote: > This is already invoked a few cycles later in monitor mode by > _secure_monitor. Drop it here, it serves no purpose. For clarity, because of the vector tables? Reviewed-by: Tom Rini <trini@konsulko.com>
Am 2015-03-11 um 16:11 schrieb Tom Rini: > On Mon, Mar 09, 2015 at 08:00:11AM +0100, Jan Kiszka wrote: > >> This is already invoked a few cycles later in monitor mode by >> _secure_monitor. Drop it here, it serves no purpose. > > For clarity, because of the vector tables? Sorry, didn't get the question yet. Are you asking why it was added initially (that would be a question for Marc) or why it serves no purpose now? Jan
On Thu, Mar 12, 2015 at 08:34:34AM +0100, Jan Kiszka wrote: > Am 2015-03-11 um 16:11 schrieb Tom Rini: > > On Mon, Mar 09, 2015 at 08:00:11AM +0100, Jan Kiszka wrote: > > > >> This is already invoked a few cycles later in monitor mode by > >> _secure_monitor. Drop it here, it serves no purpose. > > > > For clarity, because of the vector tables? > > Sorry, didn't get the question yet. Are you asking why it was added > initially (that would be a question for Marc) or why it serves no > purpose now? You're saying we can drop the call to that function from where it was because it's called a few cycles later. In mainline we would only (as far as I can see) call the function because the CPU went to the vector table and called it that way. Or rather, I'm unclear as to how the function would be called a few cycles later, can you please expand the commit message to make it clearer? Thanks!
Am 2015-03-12 um 13:28 schrieb Tom Rini: > On Thu, Mar 12, 2015 at 08:34:34AM +0100, Jan Kiszka wrote: >> Am 2015-03-11 um 16:11 schrieb Tom Rini: >>> On Mon, Mar 09, 2015 at 08:00:11AM +0100, Jan Kiszka wrote: >>> >>>> This is already invoked a few cycles later in monitor mode by >>>> _secure_monitor. Drop it here, it serves no purpose. >>> >>> For clarity, because of the vector tables? >> >> Sorry, didn't get the question yet. Are you asking why it was added >> initially (that would be a question for Marc) or why it serves no >> purpose now? > > You're saying we can drop the call to that function from where it was > because it's called a few cycles later. In mainline we would only (as > far as I can see) call the function because the CPU went to the vector > table and called it that way. > > Or rather, I'm unclear as to how the function would be called a few > cycles later, can you please expand the commit message to make it > clearer? Thanks! Yeah, the call chain continues like this: _sunxi_cpu_entry calls _do_nonsec_entry which which triggers via smc #0 _secure_monitor, and there we have the second invocation. There is no alternative path. Better? Jan
Hi, On 11-03-15 16:11, Tom Rini wrote: > On Mon, Mar 09, 2015 at 08:00:11AM +0100, Jan Kiszka wrote: > >> This is already invoked a few cycles later in monitor mode by >> _secure_monitor. Drop it here, it serves no purpose. > > For clarity, because of the vector tables? > > Reviewed-by: Tom Rini <trini@konsulko.com> I've just given this a test run on an A20 board and everything psci related still works fine, so: Tested-by: Hans de Goede <hdegoede@redhat.com> Regards, Hans
diff --git a/arch/arm/cpu/armv7/sunxi/psci.S b/arch/arm/cpu/armv7/sunxi/psci.S index 5be497b..9e898f2 100644 --- a/arch/arm/cpu/armv7/sunxi/psci.S +++ b/arch/arm/cpu/armv7/sunxi/psci.S @@ -254,7 +254,6 @@ _sunxi_cpu_entry: isb bl _nonsec_init - bl psci_arch_init adr r0, _target_pc ldr r0, [r0]
This is already invoked a few cycles later in monitor mode by _secure_monitor. Drop it here, it serves no purpose. CC: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- arch/arm/cpu/armv7/sunxi/psci.S | 1 - 1 file changed, 1 deletion(-)