On 2022/9/1 1:36, Stephen Boyd wrote:
Quoting Fenglin Wu (2022-06-11 20:24:44)
From: David Collins <collinsd@xxxxxxxxxxxxxx>
Make all interrupt related properties as optional instead of
required. Some boards do not required PMIC IRQ support and it
isn't needed to handle SPMI bus transactions, so specify it as
optional.
Signed-off-by: David Collins <collinsd@xxxxxxxxxxxxxx>
Signed-off-by: Fenglin Wu <quic_fenglinw@xxxxxxxxxxx>
Acked-by: Rob Herring <robh@xxxxxxxxxx>
---
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
index 55d379c..fee4f0e 100644
--- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
@@ -88,9 +88,6 @@ properties:
required:
- compatible
- reg-names
- - interrupts
- - interrupt-names
- - '#interrupt-cells'
Let me clarify my comment on the next driver patch here. It looks like
we're making the properties optional here so that the driver can choose
to create or not create the irqchip based on the presence of the
property. Are there PMIC arbiters that don't have irq support? Or is it
only that some board designs don't use interrupt support of the PMIC,
because all the devices that use interrupts on the PMIC aren't enabled
(status = "okay")?
We shouldn't get into a situation where we're removing the interrupt
properties because we want the driver to skip creating the irqchip. That
makes the binding too loose, where we can't validate existing DT files.
It also makes it confusing to include the DTS files when the device
always supports interrupt capabilities, just we don't want to use it.
Thanks for reviewing the changes Stephen.
I discussed with the change author David, he mentioned that these two
changes were made for supporting trust VM features. In the design, there
are two SPMI arbiter device instances, one is in non-secure world (with
Linux Android) and the other is in secure world (with LE), both
instances use the same SPMI arbiter driver but only the LA system
handles the interrupt, and the irqchip will not be created for LE system
to prevent any interrupt being fired and routed to the LA system.
There are actually two other changes in SPMI driver made for the same
secure VM feature. The driver exports a new API which would translate
the SPMI address (SID+PID+OFFSET) into the SoC physical register address
range that handles the SPMI write to the corresponding SPMI registers,
and the secure system would do some protection on these registers to
block any SPMI write from non-secure world when the secure feature is
enabled.
There will be 4 changes related in total, I will send them together with
a new topic next time and you can help to review them after that.
Thank you!
