Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <026bf48f-caf1-2d1e-b4de-553a6625a51b@deltatee.com>
Date:   Mon, 21 Mar 2022 10:30:19 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.2
Content-Language: en-CA
To:     Shlomo Pongratz <shlomopongratz@gmail.com>
Cc:     linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
        andrew.maier@eideticom.com, bhelgaas@google.com,
        Shlomo Pongratz <shlomop@pliops.com>
References: <20220321143120.12191-1-shlomop@pliops.com>
 <981016a7-f994-f0dd-422e-66ac909371c7@deltatee.com>
 <302CF9D7-ACBD-49D6-AE56-4830B746CE1F@gmail.com>
From:   Logan Gunthorpe <logang@deltatee.com>
In-Reply-To: <302CF9D7-ACBD-49D6-AE56-4830B746CE1F@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH v1] Intel Sky Lake-E host root ports check.
Precedence: bulk


On 2022-03-21 10:21, Shlomo Pongratz wrote:
> See inline
> 
> Shlomo.
> 
>> On 21 Mar 2022, at 17:46, Logan Gunthorpe <logang@deltatee.com
>> <mailto:logang@deltatee.com>> wrote:
>>
>>
>>
>> On 2022-03-21 08:31, Shlomo Pongratz wrote:
>>> On commit 7b94b53db34f ("PCI/P2PDMA: Add Intel Sky Lake-E Root Ports
>>> B, C, D to the whitelist")
>>> Andrew Maier added the Sky Lake-E additional devices
>>> 2031, 2032 and 2033 root ports to the already existing 2030 device.
>>> Note that the Intel devices 2030, 2031, 2032 and 2033 are ports A, B,
>>> C and D.
>>> Consider on a bus X only port C is connected downstream so in the PCI
>>> scan only
>>> device 8086:2032 on 0000:X:02.0 will be found as bridges that have no
>>> children are ignored.
>>> As a result the routine pci_host_bridge_dev will return NULL for
>>> devices under slot C.
>>> In the proposed patch port field is added to the whitelist which is 0
>>> for 2030, 1 for 2031,
>>> 2 for 2032 3 for 2033 and 0 for all other devices.
>>
>> The patch looks largely ok, but I'm not sure I follow this description.
>>
>> It sounds like in practice the host bridges B, C and D are not addressed
>> at function 0 as was assumed. But what does it mean that only C is
>> connected downstream? How can a bridge not be connected downstream?
>>
> Maybe it is wrong usage of words.
> I mean three are no devices behind port A and B, it is possible if there
> if one has empty PCI slots.
> I my case I had only on NVMe SSD connected to port C.

If a bridge has no devices behind it, it's not ever going to get into
the p2pdma code; so I'm not sure how that's relevant. And just because
one user doesn't have any device behind a bridge, doesn't mean that all
users have no devices under that bridge.

Sounds like the commit description and comments just neeed to change to
note that the function of each of the bridge is not always zero, as
originally assumed.

Logan