All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@codeaurora.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Bjorn Helgaas <helgaas@kernel.org>
Cc: Linux PCI <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Vikram Sethi <vikrams@codeaurora.org>,
	alex.williamson@redhat.com
Subject: Re: PCI CRS Support
Date: Sun, 28 Aug 2016 13:57:00 -0400	[thread overview]
Message-ID: <53c02b52-648d-d64b-a348-b27873e32ab3@codeaurora.org> (raw)
In-Reply-To: <20160825084441.GA9025@red-moon>

Hi Bjorn, Lorenzo;

On 8/25/2016 4:44 AM, Lorenzo Pieralisi wrote:
> Hi Sinan,
> 
> [+Alex]
> 
> On Wed, Aug 24, 2016 at 03:28:51PM -0400, Sinan Kaya wrote:
>> On 8/24/2016 3:10 PM, Bjorn Helgaas wrote:
>>>> Where do we go from here? I was thinking of putting something deep down into the reset secondary
>>>>> bus function but I'm afraid it will break things especially when we wait up to 60 seconds.
>>> I agree CRS handling after reset is probably all broken.
>>>
>>> I hate the fact that we reset devices without re-enumerating them.  We
>>> have no assurance that the device is the same after reset (it could
>>> have loaded new firmware and been completely reconfigured).
>>>
>>> I don't have any good suggestions for you, so if you have some ideas
>>> and want to fix it, please go ahead.
>>
>> I think I'll make a list of paths that reach to secondary bus reset
>> function and try to keep CRS loop as close as possible to the caller. 
>>
>> I'll focus on FLR later. I won't be heart-broken if somebody took a
>> stab at the FLR.
> 
> Side note, taking advantage of this query: I hope this is a problem
> solved by end of October, if it is not I would suggest adding a track to
> tackle it at LPC16 PCI uconf, I added Alex since I know he is interested
> in the topic too, it makes sense to debate a solution with all
> interested people in one room.
> 

Let's see where this goes.

Here is a list of all the callers I found. Based on what I see, the code
assumes that registers are accessible immediately after pci_reset_bridge_secondary_bus
call.

pci_reset_bridge_secondary_bus also sleeps for 1 seconds. We can maybe assume
that it is OK to sleep additional potential 60 seconds. 

How do you feel about running CRS against all immediate children
of this bridge in pci_reset_secondary_bus function by calling pci_bus_read_dev_vendor_id
for every single child?

Something like:

+ u32 l;

+ list_for_each_entry(dev, &bus->devices, bus_list)
+ 	pci_bus_read_dev_vendor_id(bus, dev->devfn, &l, 60*1000);



trigger_sbr (infiniband/hw/hfi1/pcie.c)
	pci_reset_bridge_secondary_bus (export)
		pcibios_reset_secondary_bus	 (weak)
			pci_reset_secondary_bus

__pci_reset_function
	pci_dev_reset
		__pci_dev_reset
			pci_dev_reset_slot_function
				pci_reset_hotplug_slot
					reset_slot (drivers/pci/hotplug/pciehp_core.c)
						pciehp_reset_slot (drivers/pci/hotplug/pciehp_hpc.c)
							pci_reset_bridge_secondary_bus (export)
								pcibios_reset_secondary_bus	 (weak)
									pci_reset_secondary_bus

							pcie_capability_write_word


			pci_parent_bus_reset
				pci_reset_bridge_secondary_bus
					pcibios_reset_secondary_bus	 (weak)
						pci_reset_secondary_bus

pci_try_reset_function
	__pci_dev_reset
	pci_dev_restore

pcistub_put_pci_dev
	__pci_reset_function_locked
		__pci_dev_reset
	pci_restore_state

pcistub_init_device
	__pci_reset_function_locked
		__pci_dev_reset
	pci_restore_state

handle_error_source
	do_recovery
		reset_link (drivers/pci/pcie/aer/aerdrv_core.c)
			default_reset_link
				pci_reset_bridge_secondary_bus (export)
					pcibios_reset_secondary_bus	 (weak)
						pci_reset_secondary_bus


			driver->reset_link
				aer_root_reset
					pci_reset_bridge_secondary_bus (export)
						pcibios_reset_secondary_bus	 (weak)
							pci_reset_secondary_bus
					pci_read_config_dword

vfio_pci_ioctl (VFIO_DEVICE_PCI_HOT_RESET)
	pci_try_reset_bus
		pci_reset_bridge_secondary_bus
			pcibios_reset_secondary_bus	 (weak)
				pci_reset_secondary_bus

vfio_pci_disable
	vfio_pci_try_bus_reset
		pci_try_reset_bus
			pci_reset_bridge_secondary_bus
				pcibios_reset_secondary_bus	 (weak)
					pci_reset_secondary_bus

	pci_probe_reset_bus (probe =1)
		pci_bus_reset
			pci_reset_bridge_secondary_bus
				pcibios_reset_secondary_bus	 (weak)
					pci_reset_secondary_bus

vfio_pci_ioctl ( VFIO_DEVICE_GET_PCI_HOT_RESET_INFO)
	pci_probe_reset_bus (probe =1)
		pci_bus_reset
			pci_reset_bridge_secondary_bus
				pcibios_reset_secondary_bus	 (weak)
					pci_reset_secondary_bus

pci_reset_bus (no caller)
	pci_probe_reset_bus (probe =1)
		pci_bus_reset
			pci_reset_bridge_secondary_bus
				pcibios_reset_secondary_bus	 (weak)
					pci_reset_secondary_bus




-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

      reply	other threads:[~2016-08-28 17:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-24 15:56 PCI CRS Support Sinan Kaya
2016-08-24 19:10 ` Bjorn Helgaas
2016-08-24 19:28   ` Sinan Kaya
2016-08-25  8:44     ` Lorenzo Pieralisi
2016-08-28 17:57       ` Sinan Kaya [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53c02b52-648d-d64b-a348-b27873e32ab3@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=vikrams@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.