linux-kernel - Re: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices

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: <56B9256A.5040106@caviumnetworks.com>
Date:	Mon, 8 Feb 2016 15:31:54 -0800
From:	David Daney <ddaney@...iumnetworks.com>
To:	Bjorn Helgaas <helgaas@...nel.org>
CC:	Rob Herring <robh@...nel.org>, David Daney <ddaney.cavm@...il.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Will Deacon <will.deacon@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Daney <david.daney@...ium.com>
Subject: Re: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1
 on-chip devices

On 02/08/2016 03:24 PM, Bjorn Helgaas wrote:
> On Mon, Feb 08, 2016 at 02:41:41PM -0800, David Daney wrote:
>> On 02/08/2016 02:12 PM, Bjorn Helgaas wrote:
>>> On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote:
>>>> On 02/08/2016 01:12 PM, Rob Herring wrote:
>>>>> On Mon, Feb 8, 2016 at 2:47 PM, David Daney <ddaney@...iumnetworks.com> wrote:
>>>>>> On 02/08/2016 11:56 AM, Rob Herring wrote:
>>>>>>> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
>>>>>>>> From: David Daney <david.daney@...ium.com>
>>>>>>>> +Properties of the host controller node that differ from
>>>>>>>> +host-generic-pci.txt:
>>>>>>>> +
>>>>>>>> +- compatible     : Must be "cavium,pci-host-thunder-ecam"
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +
>>>>>>>> +       pci@...0,00000000 {
>> ...
>>>>>>> and the node name should be "pcie".
>>>>>>
>>>>>> Why pcie?
>>>>>>
>>>>>> There are no PCIe devices or buses reachable from this type of root complex.
>>>>>> There are however many PCI devices.
>> ...
>
>>>> Really, it is a bit of a gray area here as we don't have any bridges
>>>> to PCIe buses and there are multiple devices residing on each bus,
>>>> so from that point of view it cannot be PCIe.  There are, however,
>>>> devices that implement the PCI Express Capability structure, so does
>>>> that make it PCIe?  It is not clear what the specifications demand
>>>> here.
>>>
>>> The PCI core doesn't care about the node name in the device tree.  But
>>> it *does* care about some details of PCI/PCIe topology.  We consider
>>> anything with a PCIe capability to be PCIe.  For example,
>>>
>>>    - pci_cfg_space_size() thinks PCIe devices have 4K of config space
>>>
>>>    - only_one_child() thinks a PCIe bus, i.e., a link, only has a
>>>      single device on it
>>>
>>>    - a PCIe device should have a PCIe Root Port or PCIe Downstream Port
>>>      upstream from it (we did remove some of these restrictions with
>>>      b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but
>>>      it's possible we didn't get them all)
>>>
>>> I assume your system conforms to expectations like these; I'm just
>>> pointing them out because you mentioned buses with multiple devices on
>>> them, which is definitely something one doesn't expect in PCIe.
>>
>> The topology we have is currently working with the kernel's core PCI
>> code.  I don't really want to get into discussing what the
>> definition of PCIe is.  We have multiple devices (more than 32) on a
>> single bus, and they have PCI Express and ARI Capabilities.  Is that
>> PCIe?  I don't know.
>
> I don't need to know the details of your topology.  As long as it
> conforms to the PCIe spec, it should be fine.  If it *doesn't* conform
> to the spec, but things currently seem to work, that's less fine,
> because a future Linux change is liable to break something for you.
>
> I was a little concerned about your statement that "there are multiple
> devices residing on each bus, so from that point of view it cannot be
> PCIe."  That made it sound like you're doing something outside the
> spec.  If you're just using regular multi-function devices or ARI,
> then I don't see any issue (or any reason to say it can't be PCIe).

OK, I will make it "pcie@...."

Really, ARI is the only reason.  But since ARI is defined in the PCI 
Express specification, pcie it is.

I will send revised patches today.


David Daney

>
> Bjorn
>