Message ID | 1675188609-20913-1-git-send-email-ssengar@linux.microsoft.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp53837wrn; Tue, 31 Jan 2023 10:13:38 -0800 (PST) X-Google-Smtp-Source: AK7set/lg347Sq4FtCMLlEYcSeJaUTMZaTZRCRrnujvsoucnk1MSbSFyvJSGX0I/E9b/EEH+7P9p X-Received: by 2002:a17:90a:199d:b0:22c:169b:ec47 with SMTP id 29-20020a17090a199d00b0022c169bec47mr23724291pji.41.1675188818003; Tue, 31 Jan 2023 10:13:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675188817; cv=none; d=google.com; s=arc-20160816; b=LZBe8LQYNMaHEcsHpMxJ/1qfaMLr8FK5cWjtjA9DcvZphZ4wV54f2q0C/+1/eVPRHk EbIOKLEDMZqAWX5Hwy0ADEnZIdKezDytDDJvI6LSyA37MV2uPK1fg4Z8xdcUVWK9fZHE xJJRzGnASV/+vttPhCtyRKAL9Y75O7+dSFYjkA+j+Hoc38o7tdSZWrbtOPy0ttxCWa30 lkc+RNet5zQcGV3UdShCIHOHleAgFMxxbx17ULBjoddLr5Bf3jSxnCUTzuuJVKfQEVuS Die09rIle4lP5r3L9bybzgMPPJpMMoPV2aBfNpFTb3cYfprR7J9P8Ax8zKZnFJFk+YUM Fk5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:to:from:dkim-signature :dkim-filter; bh=Njh2hRh/Sz5JeDXwWgVBU7GskswtLNmWD2gVdeP5sDo=; b=OgHqpCUL2Sq6lhpBzDa5MXVQLfg/tlNopNBtCTH1qCCUI/aS1lSjctO2pLVHuQh2OQ in6kY44tkrbWffTf3CAkru0ukH4mwiL6xKc1GR+RgND61DlJ2XwtMQpjaxRTwzuCM/dZ N7oqRFigI5QG7WIOWDljFjv9PDsg+KWl9dVf4WVfn2txCuQ10uKlHTdFJsbgpE0L1Yi5 N/BwiUBpnolmnFCZ4e+qa24zpWvjbvlrW3ShYEODBFrIIOrbjFdkbwdLaqV3mXeSrQPe PoumoDnBaBseeOXlIOdmoRAnSNxTKND/4NCH77CF8LwLaIt4ABBIjyZ+nf1NnZBs/BxN IsQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=KoKMr9fU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id oc7-20020a17090b1c0700b00230270f51e0si1057691pjb.127.2023.01.31.10.13.25; Tue, 31 Jan 2023 10:13:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=KoKMr9fU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229868AbjAaSKV (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Tue, 31 Jan 2023 13:10:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229504AbjAaSKS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 31 Jan 2023 13:10:18 -0500 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7504A19F1A; Tue, 31 Jan 2023 10:10:17 -0800 (PST) Received: from linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net (linux.microsoft.com [13.77.154.182]) by linux.microsoft.com (Postfix) with ESMTPSA id 2029820B3712; Tue, 31 Jan 2023 10:10:17 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 2029820B3712 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1675188617; bh=Njh2hRh/Sz5JeDXwWgVBU7GskswtLNmWD2gVdeP5sDo=; h=From:To:Subject:Date:From; b=KoKMr9fUhL6pfBllkuhz7ca/wt7QrhqkgvwDTJ3y/hc1hPnSDn/36xEv2L48bOKgE BOhapBtyOuL6reBYAhNFadtV15LvStvquTEaB4FDSKwlACe0xS9pm9zipIU+mtZpS7 QdoW2Ap/o5Og2yDI0a4EbSJ4+IKj4Q0WCAbV41xc= From: Saurabh Sengar <ssengar@linux.microsoft.com> To: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, daniel.lezcano@linaro.org, tglx@linutronix.de, virtualization@lists.linux-foundation.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, mikelley@microsoft.com, ssengar@microsoft.com Subject: [PATCH v2 0/6] Device tree support for Hyper-V VMBus driver Date: Tue, 31 Jan 2023 10:10:03 -0800 Message-Id: <1675188609-20913-1-git-send-email-ssengar@linux.microsoft.com> X-Mailer: git-send-email 1.8.3.1 X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756562790208468178?= X-GMAIL-MSGID: =?utf-8?q?1756562790208468178?= |
Series |
Device tree support for Hyper-V VMBus driver
|
|
Message
Saurabh Singh Sengar
Jan. 31, 2023, 6:10 p.m. UTC
This set of patches expands the VMBus driver to include device tree support. The first two patches enable compilation of Hyper-V APIs in a non-ACPI build. The third patch converts the VMBus driver from acpi to more generic platform driver. Further to add device tree documentation for VMBus, it needs to club with other virtualization driver's documentation. For this rename the virtio folder to more generic hypervisor, so that all the hypervisor based devices can co-exist in a single place in device tree documentation. The fourth patch does this renaming. The fifth patch introduces the device tree documentation for VMBus. The sixth patch adds device tree support to the VMBus driver. Currently this is tested only for x86 and it may not work for other archs. [v2] - Convert VMBus acpi device to platform device, and added device tree support in separate patch. This enables using same driver structure for both the flows. - In Device tree documentation, changed virtio folder to hypervisor and moved VMBus documentation there. - Moved bindings before Device tree patch. - Removed stale ".data" and ".name" field from of_device match table. - Removed debug print. - Fix "make DT_CHECKER_FLAGS=-m dt_binding_check" warnings. Saurabh Sengar (6): drivers/clocksource/hyper-v: non ACPI support in hyperv clock Drivers: hv: allow non ACPI compilation for hv_is_hibernation_supported Drivers: hv: vmbus: Convert acpi_device to platform_device dt-bindings: hypervisor: Rename virtio to hypervisor dt-bindings: hypervisor: Add dt-bindings for VMBus Driver: VMBus: Add device tree support .../bindings/{virtio => hypervisor}/mmio.yaml | 2 +- .../bindings/hypervisor/msft,vmbus.yaml | 50 ++++++ .../{virtio => hypervisor}/pci-iommu.yaml | 2 +- .../{virtio => hypervisor}/virtio-device.yaml | 2 +- .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 3 +- drivers/clocksource/hyperv_timer.c | 15 +- drivers/hv/hv_common.c | 4 + drivers/hv/vmbus_drv.c | 153 ++++++++++++++---- 9 files changed, 193 insertions(+), 40 deletions(-) rename Documentation/devicetree/bindings/{virtio => hypervisor}/mmio.yaml (95%) create mode 100644 Documentation/devicetree/bindings/hypervisor/msft,vmbus.yaml rename Documentation/devicetree/bindings/{virtio => hypervisor}/pci-iommu.yaml (98%) rename Documentation/devicetree/bindings/{virtio => hypervisor}/virtio-device.yaml (93%)
Comments
On Tue, Jan 31, 2023 at 12:10 PM Saurabh Sengar <ssengar@linux.microsoft.com> wrote: > > This set of patches expands the VMBus driver to include device tree > support. > > The first two patches enable compilation of Hyper-V APIs in a non-ACPI > build. > > The third patch converts the VMBus driver from acpi to more generic > platform driver. > > Further to add device tree documentation for VMBus, it needs to club with > other virtualization driver's documentation. For this rename the virtio > folder to more generic hypervisor, so that all the hypervisor based > devices can co-exist in a single place in device tree documentation. The > fourth patch does this renaming. > > The fifth patch introduces the device tree documentation for VMBus. > > The sixth patch adds device tree support to the VMBus driver. Currently > this is tested only for x86 and it may not work for other archs. I can read all the patches and see *what* they do. You don't really need to list that here. I'm still wondering *why*. That is what the cover letter and commit messages should answer. Why do you need DT support? How does this even work on x86? FDT is only enabled for CE4100 platform. Rob
On Tue, Jan 31, 2023 at 02:27:51PM -0600, Rob Herring wrote: > On Tue, Jan 31, 2023 at 12:10 PM Saurabh Sengar > <ssengar@linux.microsoft.com> wrote: > > > > This set of patches expands the VMBus driver to include device tree > > support. > > > > The first two patches enable compilation of Hyper-V APIs in a non-ACPI > > build. > > > > The third patch converts the VMBus driver from acpi to more generic > > platform driver. > > > > Further to add device tree documentation for VMBus, it needs to club with > > other virtualization driver's documentation. For this rename the virtio > > folder to more generic hypervisor, so that all the hypervisor based > > devices can co-exist in a single place in device tree documentation. The > > fourth patch does this renaming. > > > > The fifth patch introduces the device tree documentation for VMBus. > > > > The sixth patch adds device tree support to the VMBus driver. Currently > > this is tested only for x86 and it may not work for other archs. > > I can read all the patches and see *what* they do. You don't really > need to list that here. I'm still wondering *why*. That is what the > cover letter and commit messages should answer. Why do you need DT > support? How does this even work on x86? FDT is only enabled for > CE4100 platform. HI Rob, Thanks for your comments. We are working on a solution where kernel is booted without ACPI tables to keep the overall system's memory footprints slim and possibly faster boot time. We have tested this by enabling CONFIG_OF for x86. I can add this info in cover letter in next version. Regards, Saurabh > > Rob
On Tue, Jan 31, 2023 at 06:04:49PM -0800, Saurabh Singh Sengar wrote: > On Tue, Jan 31, 2023 at 02:27:51PM -0600, Rob Herring wrote: > > On Tue, Jan 31, 2023 at 12:10 PM Saurabh Sengar > > <ssengar@linux.microsoft.com> wrote: > > > > > > This set of patches expands the VMBus driver to include device tree > > > support. > > > > > > The first two patches enable compilation of Hyper-V APIs in a non-ACPI > > > build. > > > > > > The third patch converts the VMBus driver from acpi to more generic > > > platform driver. > > > > > > Further to add device tree documentation for VMBus, it needs to club with > > > other virtualization driver's documentation. For this rename the virtio > > > folder to more generic hypervisor, so that all the hypervisor based > > > devices can co-exist in a single place in device tree documentation. The > > > fourth patch does this renaming. > > > > > > The fifth patch introduces the device tree documentation for VMBus. > > > > > > The sixth patch adds device tree support to the VMBus driver. Currently > > > this is tested only for x86 and it may not work for other archs. > > > > I can read all the patches and see *what* they do. You don't really > > need to list that here. I'm still wondering *why*. That is what the > > cover letter and commit messages should answer. Why do you need DT > > support? How does this even work on x86? FDT is only enabled for > > CE4100 platform. > > HI Rob, > > Thanks for your comments. > We are working on a solution where kernel is booted without ACPI tables to keep > the overall system's memory footprints slim and possibly faster boot time. > We have tested this by enabling CONFIG_OF for x86. It's CONFIG_OF_EARLY_FLATTREE which you would need and that's not user selectable. At a minimum, you need some kconfig changes. Where are those? Also see my comment on v1 about running DT validation on your dtb. I'm sure running it would point out other issues. Such as the root level comaptible string(s) need to be documented. You need cpu nodes, interrupt controller, timers, etc. Those all have to be documented. Rob
On Wed, Feb 01, 2023 at 08:51:46AM -0600, Rob Herring wrote: > On Tue, Jan 31, 2023 at 06:04:49PM -0800, Saurabh Singh Sengar wrote: > > On Tue, Jan 31, 2023 at 02:27:51PM -0600, Rob Herring wrote: > > > On Tue, Jan 31, 2023 at 12:10 PM Saurabh Sengar > > > <ssengar@linux.microsoft.com> wrote: > > > > > > > > This set of patches expands the VMBus driver to include device tree > > > > support. > > > > > > > > The first two patches enable compilation of Hyper-V APIs in a non-ACPI > > > > build. > > > > > > > > The third patch converts the VMBus driver from acpi to more generic > > > > platform driver. > > > > > > > > Further to add device tree documentation for VMBus, it needs to club with > > > > other virtualization driver's documentation. For this rename the virtio > > > > folder to more generic hypervisor, so that all the hypervisor based > > > > devices can co-exist in a single place in device tree documentation. The > > > > fourth patch does this renaming. > > > > > > > > The fifth patch introduces the device tree documentation for VMBus. > > > > > > > > The sixth patch adds device tree support to the VMBus driver. Currently > > > > this is tested only for x86 and it may not work for other archs. > > > > > > I can read all the patches and see *what* they do. You don't really > > > need to list that here. I'm still wondering *why*. That is what the > > > cover letter and commit messages should answer. Why do you need DT > > > support? How does this even work on x86? FDT is only enabled for > > > CE4100 platform. > > > > HI Rob, > > > > Thanks for your comments. > > We are working on a solution where kernel is booted without ACPI tables to keep > > the overall system's memory footprints slim and possibly faster boot time. > > We have tested this by enabling CONFIG_OF for x86. > > It's CONFIG_OF_EARLY_FLATTREE which you would need and that's not user > selectable. At a minimum, you need some kconfig changes. Where are > those? You are right we have define a new config flag in Kconfig, and selected CONFIG_OF and CONFIG_OF_EARLY_FLATTREE. We are working on upstreaming that patch as well however that will be a separate patch series. > > Also see my comment on v1 about running DT validation on your dtb. I'm > sure running it would point out other issues. Such as the root level > comaptible string(s) need to be documented. You need cpu nodes, > interrupt controller, timers, etc. Those all have to be documented. I will be changing the parent node to soc node as suggested by Krzysztof in other thread. soc { #address-cells = <2>; #size-cells = <2>; vmbus@ff0000000 { #address-cells = <2>; #size-cells = <1>; compatible = "Microsoft,vmbus"; ranges = <0x00 0x00 0x0f 0xf0000000 0x10000000>; }; }; This will be sufficient. Regards, Saurabh > > Rob
On 01/02/2023 17:34, Saurabh Singh Sengar wrote: >> Also see my comment on v1 about running DT validation on your dtb. I'm >> sure running it would point out other issues. Such as the root level >> comaptible string(s) need to be documented. You need cpu nodes, >> interrupt controller, timers, etc. Those all have to be documented. > > I will be changing the parent node to soc node as suggested by Krzysztof > in other thread. > > soc { > #address-cells = <2>; > #size-cells = <2>; > > vmbus@ff0000000 { > #address-cells = <2>; > #size-cells = <1>; > compatible = "Microsoft,vmbus"; > ranges = <0x00 0x00 0x0f 0xf0000000 0x10000000>; > }; > }; > > This will be sufficient. It will be ok for the example, but will not be ok for supporting your use case. Please solve all the points from Rob's comment above. Where is their documentation? Best regards, Krzysztof
On Wed, Feb 01, 2023 at 06:15:23PM +0100, Krzysztof Kozlowski wrote: > On 01/02/2023 17:34, Saurabh Singh Sengar wrote: > >> Also see my comment on v1 about running DT validation on your dtb. I'm > >> sure running it would point out other issues. Such as the root level > >> comaptible string(s) need to be documented. You need cpu nodes, > >> interrupt controller, timers, etc. Those all have to be documented. > > > > I will be changing the parent node to soc node as suggested by Krzysztof > > in other thread. > > > > soc { > > #address-cells = <2>; > > #size-cells = <2>; > > > > vmbus@ff0000000 { > > #address-cells = <2>; > > #size-cells = <1>; > > compatible = "Microsoft,vmbus"; > > ranges = <0x00 0x00 0x0f 0xf0000000 0x10000000>; > > }; > > }; > > > > This will be sufficient. > > It will be ok for the example, but will not be ok for supporting your > use case. Please solve all the points from Rob's comment above. Where is > their documentation? > > Best regards, > Krzysztof Hi Rob/ Krzysztof, I am happy to update the documentation as requested. Please note that, apart from CPUs, there is no other device node in the tree. Here are some of the info related to our system: Timers: VMBus code uses a Hyper-V Synthetic timer and there is no device tree node or ACPI method required for this. This is implemented as drivers/clocksource/hyperv_timer.c Interrupt controller: The hypervisor virtualizes interrupt delivery to virtual processors. This is done through the use of a synthetic interrupt controller (SynIC) which is an extension of a virtualized local APIC. In the cpu DT nodes we have APIC ids. Below are the cpu nodes we use, please suggest if I need to update any document for it. cpus { #address-cells = <1>; #size-cells = <0>; cpu@0 { device_type = "cpu"; reg = <0>; status = "okay"; }; cpu@1 { device_type = "cpu"; reg = <1>; status = "okay"; }; }; Regards, Saurabh
On Wed, Feb 1, 2023 at 10:34 AM Saurabh Singh Sengar <ssengar@linux.microsoft.com> wrote: > > On Wed, Feb 01, 2023 at 08:51:46AM -0600, Rob Herring wrote: > > On Tue, Jan 31, 2023 at 06:04:49PM -0800, Saurabh Singh Sengar wrote: > > > On Tue, Jan 31, 2023 at 02:27:51PM -0600, Rob Herring wrote: > > > > On Tue, Jan 31, 2023 at 12:10 PM Saurabh Sengar > > > > <ssengar@linux.microsoft.com> wrote: > > > > > > > > > > This set of patches expands the VMBus driver to include device tree > > > > > support. > > > > > > > > > > The first two patches enable compilation of Hyper-V APIs in a non-ACPI > > > > > build. > > > > > > > > > > The third patch converts the VMBus driver from acpi to more generic > > > > > platform driver. > > > > > > > > > > Further to add device tree documentation for VMBus, it needs to club with > > > > > other virtualization driver's documentation. For this rename the virtio > > > > > folder to more generic hypervisor, so that all the hypervisor based > > > > > devices can co-exist in a single place in device tree documentation. The > > > > > fourth patch does this renaming. > > > > > > > > > > The fifth patch introduces the device tree documentation for VMBus. > > > > > > > > > > The sixth patch adds device tree support to the VMBus driver. Currently > > > > > this is tested only for x86 and it may not work for other archs. > > > > > > > > I can read all the patches and see *what* they do. You don't really > > > > need to list that here. I'm still wondering *why*. That is what the > > > > cover letter and commit messages should answer. Why do you need DT > > > > support? How does this even work on x86? FDT is only enabled for > > > > CE4100 platform. > > > > > > HI Rob, > > > > > > Thanks for your comments. > > > We are working on a solution where kernel is booted without ACPI tables to keep > > > the overall system's memory footprints slim and possibly faster boot time. > > > We have tested this by enabling CONFIG_OF for x86. > > > > It's CONFIG_OF_EARLY_FLATTREE which you would need and that's not user > > selectable. At a minimum, you need some kconfig changes. Where are > > those? > > You are right we have define a new config flag in Kconfig, and selected CONFIG_OF > and CONFIG_OF_EARLY_FLATTREE. We are working on upstreaming that patch as well > however that will be a separate patch series. Fair enough, but that should come first IMO. Really I just want to see a complete picture. That can be a reference to a git branch(es) or other patch series. But again, what I want to see in particular is the actual DT and validation run on it. > > Also see my comment on v1 about running DT validation on your dtb. I'm > > sure running it would point out other issues. Such as the root level > > comaptible string(s) need to be documented. You need cpu nodes, > > interrupt controller, timers, etc. Those all have to be documented. > > I will be changing the parent node to soc node as suggested by Krzysztof > in other thread. Another issue yes, but orthogonal to my comments. > > soc { > #address-cells = <2>; > #size-cells = <2>; You are missing 'ranges' here. Without it, addresses aren't translatable. You are also missing 'compatible = "simple-bus";'. This happens to work on x86 because of legacy reasons, but we don't want new cases added. > > vmbus@ff0000000 { > #address-cells = <2>; > #size-cells = <1>; > compatible = "Microsoft,vmbus"; 'Microsoft' is not a vendor prefix. > ranges = <0x00 0x00 0x0f 0xf0000000 0x10000000>; > }; > }; > > This will be sufficient. All these comments are unnecessary because the tools will now check these things and we shouldn't have to. Rob
On Tue, Jan 31, 2023 at 06:04:49PM -0800, Saurabh Singh Sengar wrote: > > We are working on a solution where kernel is booted without ACPI tables to keep > the overall system's memory footprints slim and possibly faster boot time. > We have tested this by enabling CONFIG_OF for x86. > Very interesting. Do you comparison on how slow/fast DT version w.r.t ACPI and similarly for the memory footprint ? It would be good to add those information as well. I know some systems just use ACPI static tables as they don't run ACPICA runtime interpretter, was that experimented as well or it wasn't used due to some specific(details please) limitations without it. > I can add this info in cover letter in next version. Yes please.
On Tue, Feb 07, 2023 at 11:53:54AM -0600, Rob Herring wrote: > On Wed, Feb 1, 2023 at 10:34 AM Saurabh Singh Sengar > <ssengar@linux.microsoft.com> wrote: > > > > On Wed, Feb 01, 2023 at 08:51:46AM -0600, Rob Herring wrote: > > > On Tue, Jan 31, 2023 at 06:04:49PM -0800, Saurabh Singh Sengar wrote: > > > > On Tue, Jan 31, 2023 at 02:27:51PM -0600, Rob Herring wrote: > > > > > On Tue, Jan 31, 2023 at 12:10 PM Saurabh Sengar > > > > > <ssengar@linux.microsoft.com> wrote: > > > > > > > > > > > > This set of patches expands the VMBus driver to include device tree > > > > > > support. (...) > > You are right we have define a new config flag in Kconfig, and selected CONFIG_OF > > and CONFIG_OF_EARLY_FLATTREE. We are working on upstreaming that patch as well > > however that will be a separate patch series. > > Fair enough, but that should come first IMO. Really I just want to see > a complete picture. That can be a reference to a git branch(es) or > other patch series. But again, what I want to see in particular is the > actual DT and validation run on it. Thank you for explaining the concern. I now understand it fully. I have come to the realization that enabling the vmbus device tree should not be impacted by any changes. To address this, I will add the following lines to the HYPERV Kconfig definition I used for testing: select OF if !ACPI select OF_EARLY_FLATTREE if !ACPI" > > > > Also see my comment on v1 about running DT validation on your dtb. I'm > > > sure running it would point out other issues. Such as the root level > > > comaptible string(s) need to be documented. You need cpu nodes, > > > interrupt controller, timers, etc. Those all have to be documented. > > > > I will be changing the parent node to soc node as suggested by Krzysztof > > in other thread. > > Another issue yes, but orthogonal to my comments. > > > > > soc { > > #address-cells = <2>; > > #size-cells = <2>; > > You are missing 'ranges' here. Without it, addresses aren't translatable. > > You are also missing 'compatible = "simple-bus";'. This happens to > work on x86 because of legacy reasons, but we don't want new cases > added. I am a bit unclear on the reason for adding the ranges property in the root node. To provide more context, I have included my full device tree below. I believe that having the ranges property in the VMBus device node is sufficient. Please let me know if this can be improved. /dts-v1/; / { #address-cells = <0>; #size-cells = <0>; model = "microsoft,test"; cpus { #address-cells = <0x01>; #size-cells = <0x00>; cpu@0 { device_type = "cpu"; reg = <0x00>; status = "okay"; }; cpu@1 { device_type = "cpu"; reg = <0x01>; status = "okay"; }; }; vmbus@ff0000000 { #address-cells = <2>; #size-cells = <2>; compatible = "microsoft,vmbus"; ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x0 0x10000000>; }; }; > > > > > vmbus@ff0000000 { > > #address-cells = <2>; > > #size-cells = <1>; > > compatible = "Microsoft,vmbus"; > > 'Microsoft' is not a vendor prefix. > > > ranges = <0x00 0x00 0x0f 0xf0000000 0x10000000>; > > }; > > }; > > > > This will be sufficient. > > All these comments are unnecessary because the tools will now check > these things and we shouldn't have to. Agree, and its fixed in latest version. Regards, Saurabh > > Rob