On Thu, Jan 12, 2023 at 03:54:23PM +0100, Etienne Carriere wrote:
Adds optional interrupt controller properties used when OP-TEE generates interrupt events optee driver shall notified to its registered interrupt consumer. The example shows how OP-TEE can trigger a wakeup interrupt event consumed by a gpio-keys compatible device.
Why do we need this in DT? It's not a GPIO key, but an abuse of the binding. It looks like unnecessary abstraction to me.
Signed-off-by: Etienne Carriere etienne.carriere@linaro.org
.../arm/firmware/linaro,optee-tz.yaml | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml index d4dc0749f9fd..42874ca21b7e 100644 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -40,6 +40,11 @@ properties: HVC #0, register assignments register assignments are specified in drivers/tee/optee/optee_smc.h
- interrupt-controller: true
- "#interrupt-cells":
- const: 1
required:
- compatible
- method
@@ -48,12 +53,24 @@ additionalProperties: false examples:
- |
- #include <dt-bindings/input/input.h> #include <dt-bindings/interrupt-controller/arm-gic.h> firmware {
optee {
optee: optee { compatible = "linaro,optee-tz"; method = "smc"; interrupts = <GIC_SPI 187 IRQ_TYPE_EDGE_RISING>;
interrupt-controller;
#interrupt-cells = <1>;
};
- };
- wake_up {
compatible = "gpio-keys";
button {
linux,code = <KEY_WAKEUP>;
interrupts-extended = <&optee 0>;
In the end, you just need optee IRQ #0 to generate KEY_WAKEUP. Does either the optee interrupt number or the key code need to be configurable? If so, why? Why isn't #0 just wakeup and the driver can send KEY_WAKEUP?
DT is for non-discoverable hardware that we can't fix. Why repeat that for software interfaces to firmware?
Rob