lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230217132710.GA4165@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date:   Fri, 17 Feb 2023 05:27:10 -0800
From:   Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     krzysztof.kozlowski+dt@...aro.org, kys@...rosoft.com,
        haiyangz@...rosoft.com, wei.liu@...nel.org, decui@...rosoft.com,
        daniel.lezcano@...aro.org, tglx@...utronix.de,
        virtualization@...ts.linux-foundation.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-hyperv@...r.kernel.org, mikelley@...rosoft.com,
        dphadke@...ux.microsoft.com
Subject: Re: [PATCH v5 5/5] Driver: VMBus: Add device tree support

On Mon, Feb 13, 2023 at 03:24:39AM -0800, Saurabh Singh Sengar wrote:
> On Fri, Feb 10, 2023 at 04:37:28PM -0600, Rob Herring wrote:
> > On Thu, Feb 9, 2023 at 11:46 AM Saurabh Singh Sengar
> > <ssengar@...ux.microsoft.com> wrote:
> > >
> > > On Thu, Feb 09, 2023 at 09:50:31AM -0600, Rob Herring wrote:
> > > > On Thu, Feb 9, 2023 at 6:15 AM Saurabh Sengar
> > > > <ssengar@...ux.microsoft.com> wrote:
> > > > >
> > > > > Update the driver to support device tree boot as well along with ACPI.
> > > >
> > > > Devicetree
> > 
> > [...]
> > 
> > > > > +       for_each_of_range(&parser, &range) {
> > > > > +               struct resource *res;
> > > > > +
> > > > > +               res = kzalloc(sizeof(*res), GFP_ATOMIC);
> > > > > +               if (!res)
> > > > > +                       return -ENOMEM;
> > > > > +
> > > > > +               res->name = "hyperv mmio";
> > > > > +               res->flags = IORESOURCE_MEM | IORESOURCE_MEM_64;
> > > > > +               res->start = range.pci_addr;
> > > >
> > > > This is not PCI. It's a union, so use 'bus_addr' instead.
> > > >
> > > > But wait, resources and IORESOURCE_MEM are *CPU* addresses. You need
> > > > cpu_addr here. Your DT happens to do 1:1 addresses so it happens to
> > > > work either way.
> > >
> > > bus_addr works for us, will send V6
> > 
> > Sigh. bus_addr may work, but is wrong as I explained.
> > 
> > And you've already sent v6... Please slow down your pace with sending
> > new versions. 4 versions in a week is too much. Give others time to
> > comment and me to respond to discussions. Like a week...
> 
> I apologize if my actions may have come across as overly hasty. I will make
> sure to allow for more time between submissions in the future, to ensure that
> everyone has an adequate opportunity to review and provide feedback.
> 
> Regarding the use of bus_addr instead of cpu_addr, I found that cpu_addr was
> populating as OF_BAD_ADDR while bus_addr was populating correctly.  I think
> this is because I should be defining a empty ranges property in parent node
> for indicating 1:1 mapping between parent and child.
> 
> But once I add empty ranges in property I get other warnings by dt_binding_check
> tool. After fixing all I am able to come up with below device tree example, please
> let me know if there is anything to be corrected. If this is good I will send
> the next version (offcource after a week :)) using cpu_addr.
> 
>     soc {
>         #address-cells = <2>;
>         #size-cells = <1>;
>         bus {
>             compatible = "simple-bus";
>             #address-cells = <2>;
>             #size-cells = <1>;
>             ranges;
> 
>             vmbus@...000000 {
>                 compatible = "microsoft,vmbus";
>                 #address-cells = <2>;
>                 #size-cells = <1>;
>                 ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x10000000>;
>             };
>         };
>     };
> 
> > 

Rob,

If you find the above changes satisfactory, please do let me know so that
I can send the updated version.

As far as I am aware, all the pending comments and issues have been addressed
in this series. However, if there are any remaining concerns or feedback that
require attention, please let me know.

- Saurabh

> > Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ