Hi Dave,
On 19/07/17 14:52, Dave Martin wrote:
> On Mon, May 15, 2017 at 06:43:55PM +0100, James Morse wrote:
>> The Software Delegated Exception Interface (SDEI) is an ARM standard
>> for registering callbacks from the platform firmware into the OS.
>> This is typically used to implement RAS notifications.
>>
>> Add the code for detecting the SDEI version and the framework for
>> registering and unregistering events. Subsequent patches will add the
>> arch-specific backend code and the necessary power management hooks.
>>
>> Currently only shared events are supported.
>> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
>> new file mode 100644
>> index 000000000000..d22dda5e0fed
>> --- /dev/null
>> +++ b/drivers/firmware/arm_sdei.c
>> +int sdei_mask_local_cpu(unsigned int cpu)
>> +{
>> + int err;
>> + struct arm_smccc_res res;
>> +
>> + WARN_ON(preemptible());
>> + err = invoke_sdei_fn(&res, SDEI_1_0_FN_SDEI_PE_MASK, 0, 0, 0, 0, 0);
> It seems awkward to have to declare res repeatedly when it's basically
> unused. Several callsites seem to do this. Out of context, this looks
> bug-like (though it's not a bug).
After a quick trawl, only the 'qcom' and 'optee' callers use regs other than x0.
> Could we make it explicit that the results other than x0 are unwanted by
> passing NULL instead?
Looks straightforward, the quirk buffer has the same behaviour. I will put
something together.
> invoke_sdei_fn (or some downstream function) could declare its own res
> for this case, but at least we'd only have to do that in one place.
> arm_smccc_smc() and friends (at least the C interface in the headers)
> could do something similar.
Yes, for SDEI I can reduce this weirdness by moving smccc_res up a level.
Thanks,
James
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
