On 27/10/2022 12:17, Elliot Berman wrote: > Hi Rob, > > On 10/26/2022 2:16 PM, Rob Herring wrote: >> On Thu, Oct 13, 2022 at 6:59 PM Elliot Berman <quic_eberman@xxxxxxxxxxx> wrote: >>> >>> >>> On 10/12/2022 8:56 AM, Rob Herring wrote: >>>> On Mon, Oct 10, 2022 at 05:08:29PM -0700, Elliot Berman wrote: >>>>> When Linux is booted as a guest under the Gunyah hypervisor, the Gunyah >>>>> 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. >>>>> >>>>> Signed-off-by: Elliot Berman <quic_eberman@xxxxxxxxxxx> >>>>> --- >>>>> .../bindings/firmware/gunyah-hypervisor.yaml | 87 +++++++++++++++++++ >>>>> MAINTAINERS | 1 + >>>>> 2 files changed, 88 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 000000000000..f0a14101e2fd >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml >>>>> @@ -0,0 +1,87 @@ >>>>> +# 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: >>>>> + - Murali Nalajala <quic_mnalajal@xxxxxxxxxxx> >>>>> + - Elliot Berman <quic_eberman@xxxxxxxxxxx> >>>>> + >>>>> +description: |+ >>>>> + On systems which support devicetree, Gunyah generates and overlays a deviceetree overlay which >>>> >>>> How you end up with the node (applying an overlay) is not relavent to >>>> the binding. >>>> >>>>> + describes the basic configuration of the hypervisor. Virtual machines use this information to determine >>>>> + the capability IDs of the message queues used to communicate with the Gunyah Resource Manager. >>>> >>>> Wrap at 80. That is the coding standard still though 100 is deemed >>>> allowed. And yamllint only complains at 110 because I didn't care to fix >>>> everyones lines over 100. >>>> >>>>> + See also: https://github.com/quic/gunyah-resource-manager/blob/develop/src/vm_creation/dto_construct.c >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + items: >>>>> + - const: gunyah-hypervisor-1.0 >>>>> + - const: gunyah-hypervisor >>>> >>>> 2 compatibles implies a difference between the 2. What's the difference? >>>> Where does '1.0' come from? >>>> >>> >>> There's no difference. I thought the convention was to have >>> device-specific compatible and the generic compatible. "device-specific" >>> here would be specific to version of Gunyah since it's software. >> >> No, that's just what people do because "vendor,new-soc", >> "vendor,old-soc" seems to bother them for some reason. At the end of >> the day, it's just a string identifier that means something. If >> there's no difference in that 'something', then there is no point in >> having more than one string. >> >> You only need something specific enough to discover the rest from the >> firmware. When that changes, then you add a new compatible. Of course, >> if you want existing OSs to work, then better not change the >> compatible. >> > > Thanks for the info, I'll drop the "-1.0" suffix. You still did not answer from where does 1.0 come from... Compatibles are usually expected to be specific. Best regards, Krzysztof
