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. > We do similar for firmware in the qcom,scm bindings and following that > principle. Always poor examples to follow... Rob
