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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 12 Jan 2021 12:57:59 -0800
From:   Ray Jui <>
To:     Arnd Bergmann <>
Cc:     Florian Fainelli <>,
        Bharat Gooty <>,
        devicetree <>,
        linux-kernel <>,
        Arnd Bergmann <>,
        Scott Branden <>,
        Ray Jui <>,
        linux-arm-msm <>,
        Andy Gross <>,
        Bjorn Andersson <>,
        Rob Herring <>,
        bcm-kernel-feedback-list <>,
        Zhen Lei <>,
        linux-arm-kernel <>
Subject: Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by
 empty dma-ranges

On 1/12/2021 12:40 PM, Arnd Bergmann wrote:
> On Tue, Jan 12, 2021 at 7:28 PM Ray Jui <> wrote:
>> On 2020-12-15 7:49 a.m., Arnd Bergmann wrote:
>>> On Tue, Dec 15, 2020 at 4:41 PM Florian Fainelli <> wrote:
>>>> On 12/15/2020 5:19 AM, Bharat Gooty wrote:
>>>>> Since the IOMMU is disabled and DMA engine is on 32-bit bus, We can not
>>>>> give the complete DDR for the USB DMA.
>>>>> So restricting the usable DAM size to 4GB.
>>>> Thanks, can you make this a proper patch submission along with a Fixes:
>>>> tag that is:
>>>> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
>>>> empty dma-ranges")
>>> Yes, that would be helpful, though I would appreciate a better description
>>> that explains what is actually going on: is it the device or the bus that
>>> has the 32-bit limitation, and if it is indeed a bug in the device, why do
>>> you pretend that this is a 64-bit device on a 32-bit bus instead (this
>>> could also use a comment in the dts file)?
>>>         Arnd
>> Sorry for the delay in reply. Bharat finally got time to do some
>> investigation to confirm the following:
>> These USB controllers indeed can address 64-bit. However, on the bus
>> internally, only 40-bits are connected to the interconnect of CCN. As a
>> result, the 'dma-ranges' should be modified to address 40-bit in size.
> a 40-bit range is effectively the same as a 64-bit range though, so I
> think you'll still need a driver quirk if the device cannot use the whole 40
> bit addressing but is limited to 32 bits because of a bug in its dma engine.

Bharat can correct me if I'm wrong, but I don't think we have a bug in
the USB DMA engine that causes it can only address 32-bit. I believe we
can set dma-ranges size to 40-bit here.

The dma-range property is though required to be specified, instead of
leaving it as empty, with the use of IOMMU. That seems to be a v5.10
specific behavior as I described below.



>> We also have a somewhat related question, is it true that since v5.10,
>> defining of 'dma-ranges' on the bus node where its child device node has
>> implication of IOMMU usage (through 'iommus' or 'iommu-map') is now
>> mandatory? My understanding is that the 'dma-ranges' in this scheme will
>> define the IOVA address to system address mapping required by all
>> devices on that bus. Please help to confirm if my understanding is correct
> I have not actually seen that change. In general, you should always
> have a dma-ranges property in the parent of a DMA master, I think
> we just never enforced that and fall back to a 32-bit mask by default.
>       Arnd

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4151 bytes)

Powered by blists - more mailing lists