Re: [PATCH 06/11] dt-bindings: add devicetree binding for describing arm64 SDEI firmware

[James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>]

Hi Rob,

On 19/05/17 02:48, Rob Herring wrote:
> On Mon, May 15, 2017 at 06:43:54PM +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 a new devicetree binding to describe the SDE firmware interface.

>> diff --git a/Documentation/devicetree/bindings/arm/sdei.txt b/Documentation/devicetree/bindings/arm/sdei.txt
>> new file mode 100644
>> index 000000000000..69220d995286
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/sdei.txt
>> @@ -0,0 +1,37 @@
>> +* Software Delegated Exception Interface (SDEI)
>> +
>> +Firmware implementing the SDEI functions described in ARM document number
>> +ARM DEN 0054A ("Software Delegated Exception Interface") can be used by
>> +Linux to receive notification of events such as those generated by
>> +firmware-first error handling.
> 
> Why am I reviewing bindings for RAS firmware-first events which is a 
> server thing? Just curious.

I did a bad job of explaining it: SDEI ended up being a general-purpose event
notification mechanism, one of the API calls in the spec lets an IRQ be 'bound'
to an event so its delivered to firmware, then via SDEI possibly interrupting
code that has IRQs masked.

(I will add some similar text...)

>> +
>> +The interface provides a number of API functions for registering callbacks
>> +and enabling/disabling events. Functions are invoked by trapping to the
>> +privilege level of the SDEI firmware (specified as part of the binding
>> +below) and passing arguments in a manner similar to that specified by AAPCS:
> 
> Shouldn't it be the ARM secure monitor call convention doc (forgot the 
> name) that you are following?

SMCCC... yes, that would make more sense, I just copied the PSCI binding.

'similar to .. AAPCS' should be come 'specified by SMCCC'.


>> +
>> +	 r0		=> 32-bit Function ID / return value
>> +	{r1 - r3}	=> Parameters
>> +
>> +Note that the immediate field of the trapping instruction must be set
>> +to #0.
>> +
>> +The SDEI_EVENT_REGISTER function registers a callback in the kernel
>> +text to handle the specified event number.
>> +
>> +Main node required properties:
>> +
>> + - compatible    : should contain:
>> +	* "arm,sdei-1.0" : For implementations complying to SDEI version 1.x.
>> +
>> + - method        : The method of calling the SDEI firmware. Permitted
>> +                   values are:
>> +	* "smc" : SMC #0, with the register assignments specified in this
>> +	          binding.
>> +	* "hvc" : HVC #0, with the register assignments specified in this
>> +	          binding.
> 
> When is ARM going to define a firmware interface to determine what 
> firmware interfaces are available?

Ideally the _version() calls could be probed, but SMCCC has:
> The Unknown Function Identifier must not be used to discover the presence, or
> lack of, an SMC or HVC Function.

So I think we're stuck with doing it like this...


>> +Example:
>> +	sdei {
> 
> Please specify this should be a child node of /firmware node.

Sure,


Thanks,

James
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html