From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751236AbdLAQRP (ORCPT ); Fri, 1 Dec 2017 11:17:15 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:22599 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751160AbdLAQRO (ORCPT ); Fri, 1 Dec 2017 11:17:14 -0500 Subject: Re: [Xen-devel] [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute To: Jan Beulich Cc: Juergen Gross , xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org, roger.pau@citrix.com References: <20171108230654.2981-1-Govinda.Tatti@Oracle.COM> <5A0424B7020000780018D6FA@prv-mh.provo.novell.com> <5A1EE54D020000780019335F@prv-mh.provo.novell.com> <2783ea8a-3ef3-c4dd-a592-52cf8e188ad4@oracle.com> <5A1FCF150200007800193632@prv-mh.provo.novell.com> <71644190-6e18-94a4-4da5-e65c041fb45a@oracle.com> <5A2027F00200007800193936@prv-mh.provo.novell.com> From: Govinda Tatti Organization: Oracle Corporation Message-ID: <5151c992-b4d8-7cf6-8ec6-cd8b621d6902@oracle.com> Date: Fri, 1 Dec 2017 10:16:52 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5A2027F00200007800193936@prv-mh.provo.novell.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/30/2017 8:46 AM, Jan Beulich wrote: >>>> On 30.11.17 at 15:15, wrote: >> On 11/30/2017 2:27 AM, Jan Beulich wrote: >>>>>> On 29.11.17 at 18:38, wrote: >>>>>> In the case of bus or slot reset, our goal is to reset connected PCIe >>>>>> fabric/card/endpoint. >>>>>> The connected card/endpoint can be multi-function device. So, same >>>>>> walk-through and checking >>>>>> is needed irrespective of type of reset being used. >>>>> I don't follow: The scope of other devices/functions possibly >>>>> affected by a reset depends on the type of reset, doesn't it? >>>> For PCIe platforms, both slot and bus reset endup resetting all connected >>>> device/functions on thesecondary bus (behind the root-port or >>>> downstream-port). >>> According to my understanding this contradicts the comment >>> ahead of pci_reset_slot(), which talks of multiple slots per bus. >>> In such a setup, I can't see why resetting on slot would affect >>> other slots on the same bus. At the same time the comment >>> says that the slot reset may resolve to a bus one when there's >>> just a single slot on the bus. >> For legacy PCI/PCI-X, we can have multiple slots per bus but not with >> PCI-Express >> (each link will be on a separate bus). > Is that true even for root complex integrated end points? A > random system's lspci output doesn't seem to agree with what > you say. A typical example would be USB controllers all sitting > on bus 0, but having different slot numbers. You clearly won't > be able to ever bus-reset these, and if you checked all devices > on bus 0 you would then also not be able to slot-reset them. Here, slot reset refers to any PCIe slot that implements or supports hotplug feature. The slot reset ultimately invokes "pciehp_reset_slot()". W.r.t integrated endpoints, these can be reset either through FLR or secondary bus reset methods only. Cheers GOVINDA