Re: [PATCH v14 02/25] dt-bindings: Add binding for gunyah hypervisor
From: Bjorn Andersson <andersson@kernel.org>
Date: 2023-08-05 03:31:38
Also in:
linux-arm-msm, linux-devicetree, linux-doc, lkml
On Tue, Jun 13, 2023 at 10:20:30AM -0700, Elliot Berman wrote:
When Linux is booted as a guest under the Gunyah hypervisor, the Gunyah
Is this unique to the case of booting Linux?
quoted hunk ↗ jump to hunk
Resource Manager applies a devicetree overlay describing the virtual platform configuration of the guest VM, such as the message queue capability IDs for communicating with the Resource Manager. This information is not otherwise discoverable by a VM: the Gunyah hypervisor core does not provide a direct interface to discover capability IDs nor a way to communicate with RM without having already known the corresponding message queue capability ID. Add the DT bindings that Gunyah adheres for the hypervisor node and message queues. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Elliot Berman <redacted> --- .../bindings/firmware/gunyah-hypervisor.yaml | 82 +++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yamldiff --git a/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml b/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml new file mode 100644 index 0000000000000..3fc0b043ac3cf --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml@@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/gunyah-hypervisor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Gunyah Hypervisor + +maintainers: + - Prakruthi Deepak Heragu <quic_pheragu@quicinc.com> + - Elliot Berman <quic_eberman@quicinc.com> + +description: |+ + Gunyah virtual machines use this information to determine the capability IDs + of the message queues used to communicate with the Gunyah Resource Manager. + See also: https://github.com/quic/gunyah-resource-manager/blob/develop/src/vm_creation/dto_construct.c + +properties: + compatible: + const: gunyah-hypervisor + + "#address-cells": + description: Number of cells needed to represent 64-bit capability IDs. + const: 2 + + "#size-cells": + description: must be 0, because capability IDs are not memory address + ranges and do not have a size. + const: 0 + +patternProperties: + "^gunyah-resource-mgr(@.*)?": + type: object + description: + Resource Manager node which is required to communicate to Resource + Manager VM using Gunyah Message Queues. + + properties: + compatible: + const: gunyah-resource-manager + + reg: + items: + - description: Gunyah capability ID of the TX message queue + - description: Gunyah capability ID of the RX message queue + + interrupts: + items: + - description: Interrupt for the TX message queue + - description: Interrupt for the RX message queue + + additionalProperties: false + + required: + - compatible + - reg + - interrupts + +additionalProperties: false + +required: + - compatible + - "#address-cells" + - "#size-cells" + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + hypervisor { + #address-cells = <2>; + #size-cells = <0>; + compatible = "gunyah-hypervisor";
It's typical to carry the compatible first among the properties. Unrelated to the binding itself, I don't see any code that matches this compatible, and as such will probe the resource manager. What am I missing?
+
+ gunyah-resource-mgr@0 {
+ compatible = "gunyah-resource-manager";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>, /* TX full IRQ */This is the "Tx no longer full IRQ", so the comment is misleading.
+ <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>; /* RX empty IRQ */
And this irq seems to fire when there's data in the RX queue, not when it's empty...
+ reg = <0x00000000 0x00000000>, <0x00000000 0x00000001>; + /* TX, RX cap ids */
Wrapping this differently will make the comments more useful. Regards, Bjorn
+ }; + }; -- 2.40.0
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel