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? > 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@xxxxxxxxxx> > Signed-off-by: Elliot Berman <quic_eberman@xxxxxxxxxxx> > --- > .../bindings/firmware/gunyah-hypervisor.yaml | 82 +++++++++++++++++++ > 1 file changed, 82 insertions(+) > create mode 100644 Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml > > diff --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@xxxxxxxxxxx> > + - Elliot Berman <quic_eberman@xxxxxxxxxxx> > + > +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 >
