All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andrew F. Davis" <afd@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Mark Rutland <mark.rutland@arm.com>, <linux-omap@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: OMAP: Use ARM SMC Calling Convention when OP-TEE is available
Date: Tue, 17 Dec 2019 08:14:11 -0500	[thread overview]
Message-ID: <35e4b682-0d2f-23b1-6df4-428c6bcb4d59@ti.com> (raw)
In-Reply-To: <20191216224105.GS35479@atomide.com>

On 12/16/19 5:41 PM, Tony Lindgren wrote:
> * Andrew F. Davis <afd@ti.com> [191216 22:34]:
>> On 12/16/19 4:04 PM, Tony Lindgren wrote:
>>> * Andrew F. Davis <afd@ti.com> [191216 20:57]:
>>>> Looks like the TI quirk idea is not moving forward, even the QCOM quirk
>>>> looks like it may get kicked out. arm_smccc_smc() will remain only for
>>>> SMCCC compliant calls, but it looks like a generic arm_smc() wouldn't be
>>>> too opposed upstream.
>>>
>>> Yes so it seems.
>>>
>>>> Either way this patch would still be valid as when OP-TEE is present
>>>> then arm_smccc_smc() will be the right call to make, how we handle the
>>>> legacy calls can be sorted out later if a generic SMC call is implemented.
>>>
>>> Please see my comment regarding this patch earlier in this thread
>>> pasted below for convenience:
>>>
>>> * Tony Lindgren <tony@atomide.com> [191119 16:22]:
>>>> In any case, you should do the necessary checks for HAVE_ARM_SMCCC
>>>> only once during init. I'm not sure how much checking for
>>>> "/firmware/optee" helps here, sounds like we have a broken system
>>>> if the firmware is not there while the arm_smccc_smc() should
>>>> still work just fine :)
>>>
>>> So only check once during init. And during init, you should probably
>>> also check that arm_smccc_smc() actually infd optee if
>>> "/firmware/optee" is set, and only then set set the right function
>>> pointer or some flag.
>>>
>>
>> Okay, I'll check only once and make sure the node is "okay".
> 
> Yes we don't want to parse the dts over and over.
> 
>> I'll do the check during the first call to an SMC caller, I wouldn't
>> want to pollute the OMAP generic init code for something that is only
>> called on HS platforms, plus these SMC calls are rare (only 3 calls
>> during boot of AM57x for instance) so performance is not critical, so I
>> don't want to do anything fancy like code patching :), I'll just use a flag.
> 
> Please just add omap_early_initcall() to omap-secure.c while at it
> to deal with this.
> 


omap_early_initcall()s are not called until after all the SMC calls have
already happened.

Andrew


> Regards,
> 
> Tony
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Andrew F. Davis" <afd@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: OMAP: Use ARM SMC Calling Convention when OP-TEE is available
Date: Tue, 17 Dec 2019 08:14:11 -0500	[thread overview]
Message-ID: <35e4b682-0d2f-23b1-6df4-428c6bcb4d59@ti.com> (raw)
In-Reply-To: <20191216224105.GS35479@atomide.com>

On 12/16/19 5:41 PM, Tony Lindgren wrote:
> * Andrew F. Davis <afd@ti.com> [191216 22:34]:
>> On 12/16/19 4:04 PM, Tony Lindgren wrote:
>>> * Andrew F. Davis <afd@ti.com> [191216 20:57]:
>>>> Looks like the TI quirk idea is not moving forward, even the QCOM quirk
>>>> looks like it may get kicked out. arm_smccc_smc() will remain only for
>>>> SMCCC compliant calls, but it looks like a generic arm_smc() wouldn't be
>>>> too opposed upstream.
>>>
>>> Yes so it seems.
>>>
>>>> Either way this patch would still be valid as when OP-TEE is present
>>>> then arm_smccc_smc() will be the right call to make, how we handle the
>>>> legacy calls can be sorted out later if a generic SMC call is implemented.
>>>
>>> Please see my comment regarding this patch earlier in this thread
>>> pasted below for convenience:
>>>
>>> * Tony Lindgren <tony@atomide.com> [191119 16:22]:
>>>> In any case, you should do the necessary checks for HAVE_ARM_SMCCC
>>>> only once during init. I'm not sure how much checking for
>>>> "/firmware/optee" helps here, sounds like we have a broken system
>>>> if the firmware is not there while the arm_smccc_smc() should
>>>> still work just fine :)
>>>
>>> So only check once during init. And during init, you should probably
>>> also check that arm_smccc_smc() actually infd optee if
>>> "/firmware/optee" is set, and only then set set the right function
>>> pointer or some flag.
>>>
>>
>> Okay, I'll check only once and make sure the node is "okay".
> 
> Yes we don't want to parse the dts over and over.
> 
>> I'll do the check during the first call to an SMC caller, I wouldn't
>> want to pollute the OMAP generic init code for something that is only
>> called on HS platforms, plus these SMC calls are rare (only 3 calls
>> during boot of AM57x for instance) so performance is not critical, so I
>> don't want to do anything fancy like code patching :), I'll just use a flag.
> 
> Please just add omap_early_initcall() to omap-secure.c while at it
> to deal with this.
> 


omap_early_initcall()s are not called until after all the SMC calls have
already happened.

Andrew


> Regards,
> 
> Tony
> 

  reply	other threads:[~2019-12-17 13:14 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18 16:52 [PATCH] ARM: OMAP: Use ARM SMC Calling Convention when OP-TEE is available Andrew F. Davis
2019-11-18 16:52 ` Andrew F. Davis
2019-11-18 21:57 ` Tony Lindgren
2019-11-18 22:13   ` Andrew F. Davis
2019-11-18 22:13     ` Andrew F. Davis
2019-11-18 22:31     ` Tony Lindgren
2019-11-19  1:13       ` Andrew F. Davis
2019-11-19  1:13         ` Andrew F. Davis
2019-11-19 16:21         ` Tony Lindgren
2019-11-19 16:21           ` Tony Lindgren
2019-11-19 16:30           ` Tony Lindgren
2019-11-19 16:30           ` Andrew F. Davis
2019-11-19 16:30             ` Andrew F. Davis
2019-11-19 16:42             ` Tony Lindgren
2019-11-19 18:05               ` Tony Lindgren
2019-11-19 18:20                 ` Andrew F. Davis
2019-11-19 18:20                   ` Andrew F. Davis
2019-11-19 18:32                   ` Tony Lindgren
2019-11-19 18:50                     ` Andrew F. Davis
2019-11-19 18:50                       ` Andrew F. Davis
2019-11-19 19:07                       ` Tony Lindgren
2019-11-19 19:12                         ` Andrew F. Davis
2019-11-19 19:12                           ` Andrew F. Davis
2019-11-19 19:20                           ` Tony Lindgren
2019-11-19 19:35                             ` Andrew F. Davis
2019-11-19 19:35                               ` Andrew F. Davis
2019-11-19 19:44                               ` Tony Lindgren
2019-11-19 19:59                                 ` Andrew F. Davis
2019-11-19 19:59                                   ` Andrew F. Davis
2019-12-16 20:56                                   ` Andrew F. Davis
2019-12-16 20:56                                     ` Andrew F. Davis
2019-12-16 21:04                                     ` Tony Lindgren
2019-12-16 22:34                                       ` Andrew F. Davis
2019-12-16 22:34                                         ` Andrew F. Davis
2019-12-16 22:41                                         ` Tony Lindgren
2019-12-17 13:14                                           ` Andrew F. Davis [this message]
2019-12-17 13:14                                             ` Andrew F. Davis
2019-12-17 15:07                                             ` Tony Lindgren
2019-12-17 17:01                                               ` Andrew F. Davis
2019-12-17 17:01                                                 ` Andrew F. Davis
2019-12-17 17:11                                                 ` Tony Lindgren
2019-12-17 17:18                                                   ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35e4b682-0d2f-23b1-6df4-428c6bcb4d59@ti.com \
    --to=afd@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.