linux-kernel - Re: [PATCH 00/19] Implement NTB Controller using multiple PCI EP

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: <d0c4c813-2af7-7fd4-e401-6fd5de69d4e4@ti.com>
Date:   Sat, 23 May 2020 07:17:47 +0530
From:   Kishon Vijay Abraham I <kishon@...com>
To:     Rob Herring <robh+dt@...nel.org>
CC:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Arnd Bergmann <arnd@...db.de>, Jon Mason <jdmason@...zu.us>,
        Dave Jiang <dave.jiang@...el.com>,
        Allen Hubbe <allenbh@...il.com>,
        Tom Joseph <tjoseph@...ence.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        PCI <linux-pci@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-ntb@...glegroups.com>
Subject: Re: [PATCH 00/19] Implement NTB Controller using multiple PCI EP

Hi Rob,

On 5/22/2020 9:41 PM, Rob Herring wrote:
> On Thu, May 14, 2020 at 8:59 AM Kishon Vijay Abraham I <kishon@...com> wrote:
>>
>> This series is about implementing SW defined NTB using
>> multiple endpoint instances. This series has been tested using
>> 2 endpoint instances in J7 connected to two DRA7 boards. However there
>> is nothing platform specific for the NTB functionality.
>>
>> This was presented in Linux Plumbers Conference. The presentation
>> can be found @ [1]
> 
> I'd like to know why putting this into DT is better than configfs.
> Does it solve some problem? Doing things in userspace is so much
> easier and more flexible than modifying and updating a DT.

It's a lot cleaner to have an endpoint function bound to two different endpoint
controller using device tree than configfs.

+    epf_bus {
+      compatible = "pci-epf-bus";
+
+      func@0 {
+        compatible = "pci-epf-ntb";
+        epcs = <&pcie0_ep>, <&pcie1_ep>;
+        epc-names = "primary", "secondary";
+        reg = <0>;
+        epf,vendor-id = /bits/ 16 <0x104c>;
+        epf,device-id = /bits/ 16 <0xb00d>;
+        num-mws = <4>;
+        mws-size = <0x0 0x100000>, <0x0 0x100000>, <0x0 0x100000>, <0x0 0x100000>;
+      };

For device tree, just using phandles is enough and the driver can easily parse
DT to get EPCs bound to the endpoint function
+        epcs = <&pcie0_ep>, <&pcie1_ep>;
+        epc-names = "primary", "secondary";

This would be
ln -s functions/pci-epf-ntb/func1 controllers/2900000.pcie-ep/
ln -s functions/pci-epf-ntb/func1 controllers/2910000.pcie-ep/

pci_epc_epf_link() should then maintain the order of EPC bound to EPF and
designate one as PRIMARY_INTERFACE and the second as SECONDARY_INTERFACE.
pci_epf_bind() should be made to behave differently for NTB case.

While the standard properties (like vendorid, deviceid) has configfs entries,
additional logic would be required for adding function specific fields like
num-mws and mws-size above.

While all this support could be added in configfs, it looks simpler to
represent then in DT.

> 
> I don't really think the PCI endpoint stuff is mature enough to be
> putting into DT either.

I think this will anyways come when we have to export real HW peripherals to
the remote HOST using EP controller.

Thanks
Kishon