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: <d42745b7-ef76-e584-0da2-751ac8c1cf3a@huawei.com>
Date:   Sun, 18 Oct 2020 10:10:03 +0800
From:   "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Arnd Bergmann <arnd@...db.de>
CC:     Rob Herring <robh+dt@...nel.org>, Ray Jui <rjui@...adcom.com>,
        "Scott Branden" <sbranden@...adcom.com>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by
 empty dma-ranges



On 2020/10/17 3:27, Florian Fainelli wrote:
> On 10/16/20 11:23 AM, Arnd Bergmann wrote:
>> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli <f.fainelli@...il.com> wrote:
>>> On 10/16/20 4:01 AM, Arnd Bergmann wrote:
>>>> On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei <thunder.leizhen@...wei.com> wrote:
>>>>>
>>>>> Suggested-by: Arnd Bergmann <arnd@...db.de>
>>>>> Signed-off-by: Zhen Lei <thunder.leizhen@...wei.com>
>>>>
>>>> Acked-by: Arnd Bergmann <arnd@...db.de>
>>>>
>>>> I see that at least the 'bcd' and 'xhci' devices in fact try to
>>>> use 64-bit DMA. It would be good to test this on actual
>>>> hardware to ensure that it works correctly when this is enabled.
>>>>
>>>> Ideally avoiding the swiotlb bounce buffering should only
>>>> make it faster here, but there are many chips on which
>>>> 64-bit DMA is broken in some form.
>>>
>>> Is this change really an improvement though? This 'usb' pseudo bus node
>>> could just keep being defined with #address-cells = <1> and #size-cells
>>> = <1> so as to satisfy the 'reg' definition however we could just adjust
>>> dma-ranges to indicate full 64-bit addressing capability. Would not that
>>> work?
>>
>> When #address-cells is '1', you cannot specify dma-ranges that
>> go beyond a 32-bit address range.
> 
> Would not it be enough to remove the 'dma-ranges' property though? Sorry
> for being slow here.

Remove the 'dma-ranges' property should also work. After all, it is equivalent
to the original empty dma-ranges scheme. In addition, since the IOMMU nodes are
defined, it should be enabled. Therefore, Arnd's concern about the scenario where
the IOMMU is disabled may not be triggered. All roads lead to Rome. Which solution
should be chose depends on individual preferences. For me, either solution is fine.

The third solution is to define a non-empty dma-ranges property. However, because
stingray-usb.dtsi is included in multiple files, it may not be appropriate.


> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ