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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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
