Rob Herring
2023-Feb-07 17:53 UTC
[PATCH v2 0/6] Device tree support for Hyper-V VMBus driver
On Wed, Feb 1, 2023 at 10:34 AM Saurabh Singh Sengar <ssengar at 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 at 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 at 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