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] [thread-next>] [day] [month] [year] [list]
Message-ID: <b74d3c16-a512-73dc-c94a-ef6adde5f757@gmail.com>
Date:   Thu, 20 Sep 2018 14:31:36 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Jim Quinlan <jim2101024@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        linux-pci <linux-pci@...r.kernel.org>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
        Gregory Fong <gregory.0xf0@...il.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Brian Norris <computersforpeace@...il.com>,
        Christoph Hellwig <hch@....de>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound
 traffic

On 09/20/2018 02:04 PM, Ard Biesheuvel wrote:
> On 20 September 2018 at 13:55, Florian Fainelli <f.fainelli@...il.com> wrote:
>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote:
>>> On 19 September 2018 at 07:31, Jim Quinlan <jim2101024@...il.com> wrote:
>>>> The Broadcom STB PCIe host controller is intimately related to the
>>>> memory subsystem.  This close relationship adds complexity to how cpu
>>>> system memory is mapped to PCIe memory.  Ideally, this mapping is an
>>>> identity mapping, or an identity mapping off by a constant.  Not so in
>>>> this case.
>>>>
>>>> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
>>>> of system memory.  Here is how the PCIe controller maps the
>>>> system memory to PCIe memory:
>>>>
>>>>   memc0-a@[        0....3fffffff] <=> pci@[        0....3fffffff]
>>>>   memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
>>>>   memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
>>>>   memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
>>>>   memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
>>>>   memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>>>>
>>>
>>> So is describing this as
>>>
>>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x40000000>,
>>>              <0x0 0x40000000 0x1 0x0 0x0 0x40000000>,
>>>              <0x0 0x80000000 0x0 0x40000000 0x0 0x40000000>,
>>>              <0x0 0xc0000000 0x3 0x0 0x0 0x40000000>,
>>>              <0x1 0x0 0x0 0x80000000 0x0 0x40000000>,
>>>              <0x1 0x40000000 0x0 0xc0000000 0x0 0x40000000>;
>>>
>>> not working for you? I haven't tried this myself, but since DT permits
>>> describing the inbound mappings this way, we should fix the code if it
>>> doesn't work at the moment.
>>
>> You mean encoding the memory controller index in the first cell? If that
>> works, that's indeed a much cleaner solution, though is it standard
>> compliant in any form?
> 
> No those are just memory addresses (although I may have screwed up the
> order). From Documentation/devicetree/booting-without-of.txt:
> 
> """
> Optional property:
> - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
>         (child-bus-address, parent-bus-address, length). Each triplet specified
>         describes a contiguous DMA address range.
> """
> 

Then I am confused by your comment, that's what this patch does, it adds
support for reading "dma-ranges" from Device Tree and setting up inbound
windows using that. The only caveat is that because the PCIe root
complex has some ties with the memory bus architecture it is connected
to (SCB in our case) there is still a requirement to know the
translation between a given physical address and its backing memory
controller/aperture.

-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ