Re: [PATCH v17 09/12] PCI/AER: Allow clearing Error Status Register in FF mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 3/12/20 2:52 PM, Bjorn Helgaas wrote:
On Thu, Mar 12, 2020 at 02:29:58PM -0700, Kuppuswamy Sathyanarayanan wrote:
Hi,

On 3/12/20 2:02 PM, Austin.Bolen@xxxxxxxx wrote:
On 3/12/2020 2:53 PM, Bjorn Helgaas wrote:
On Wed, Mar 11, 2020 at 04:07:59PM -0700, Kuppuswamy Sathyanarayanan wrote:
On 3/11/20 3:23 PM, Bjorn Helgaas wrote:
Is any synchronization needed here between the EDR path and the
hotplug/enumeration path?
If we want to follow the implementation note step by step (in
sequence) then we need some synchronization between EDR path and
enumeration path. But if it's OK to achieve the same end result by
following steps out of sequence then we don't need to create any
dependency between EDR and enumeration paths. Currently we follow
the latter approach.
What would the synchronization look like?

Ideally I think it would be better to follow the order in the
flowchart if it's not too onerous.  That will make the code easier to
understand.  The current situation with this dependency on pciehp and
what it will do leaves a lot of things implicit.

What happens if CONFIG_PCIE_EDR=y but CONFIG_HOTPLUG_PCI_PCIE=n?

IIUC, when DPC triggers, pciehp is what fields the DLLSC interrupt and
unbinds the drivers and removes the devices.  If that doesn't happen,
and Linux clears the DPC trigger to bring the link back up, will those
drivers try to operate uninitialized devices?

Does EDR need a dependency on CONFIG_HOTPLUG_PCI_PCIE?
   From one of Sathya's other responses:

"If hotplug is not supported then there is support to enumerate
devices via polling  or ACPI events. But a point to note
here is, enumeration path is independent of error handler path, and
hence there is no explicit trigger or event from error handler path
to enumeration path to kick start the enumeration."

The EDR standard doesn't have any dependency on hot-plug. It sounds like
in the current implementation there's some manual intervention needed if
hot-plug is not supported?
No, there is no need for manual intervention even in non hotplug
cases.

For ACPI events case, we would rely on ACPI event to kick start the
enumeration.  And for polling model, there is an independent polling
thread which will kick start the enumeration.
I'm guessing the ACPI case works via hotplug_is_native(): if
CONFIG_HOTPLUG_PCI_PCIE=n, pciehp_is_native() returns false, and
acpiphp manages hotplug.

What if CONFIG_HOTPLUG_PCI_ACPI=n also?
If none of the auto scans are enabled then we might need some
manual trigger ( rescan). But this would be needed in native
DPC case as well.

Where is the polling thread?
drivers/pci/hotplug/pciehp_hpc.c

Above both enumeration models are totally independent and has
no dependency on error handler thread.
I see they're currently independent from the EDR thread, but it's not
clear to me that there's no dependency.  After all, both EDR and the
hotplug paths are operating on the same devices at roughly the same
time, so we should have some story about what keeps them from getting
in each other's way.

We will decide which model to use based on hardware capability and
_OSC negotiation or kernel command line option.

--
Sathyanarayanan Kuppuswamy
Linux kernel developer




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux