* [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow @ 2018-08-09 14:57 Bharat Kumar Gogada 2018-08-09 15:11 ` poza 2018-09-05 20:04 ` Bjorn Helgaas 0 siblings, 2 replies; 6+ messages in thread From: Bharat Kumar Gogada @ 2018-08-09 14:57 UTC (permalink / raw) To: linux-pci, linux-kernel; +Cc: bhelgaas, rgummal, Bharat Kumar Gogada As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages will be forwarded from the secondary interface to the primary interface, if the SERR# Enable bit in the Bridge Control register is set. Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. This patch enables PCI_BRIDGE_CTL_SERR for Type-1 PCI device. Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> --- drivers/pci/pcie/aer.c | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c index a2e8838..4fb0d24 100644 --- a/drivers/pci/pcie/aer.c +++ b/drivers/pci/pcie/aer.c @@ -343,6 +343,20 @@ int pci_enable_pcie_error_reporting(struct pci_dev *dev) if (!dev->aer_cap) return -EIO; + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { + u16 control; + + /* + * A Type-1 PCI bridge will not forward ERR_ messages coming + * from an endpoint if SERR# forwarding is not enabled. + */ + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); + if (!(control & PCI_BRIDGE_CTL_SERR)) { + control |= PCI_BRIDGE_CTL_SERR; + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); + } + } + return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_AER_FLAGS); } EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting); @@ -352,6 +366,15 @@ int pci_disable_pcie_error_reporting(struct pci_dev *dev) if (pcie_aer_get_firmware_first(dev)) return -EIO; + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { + u16 control; + + /* Clear SERR Forwarding */ + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); + control &= ~PCI_BRIDGE_CTL_SERR; + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); + } + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, PCI_EXP_AER_FLAGS); } -- 1.7.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow 2018-08-09 14:57 [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow Bharat Kumar Gogada @ 2018-08-09 15:11 ` poza 2018-08-24 12:13 ` Bharat Kumar Gogada 2018-09-05 20:10 ` Bjorn Helgaas 2018-09-05 20:04 ` Bjorn Helgaas 1 sibling, 2 replies; 6+ messages in thread From: poza @ 2018-08-09 15:11 UTC (permalink / raw) To: Bharat Kumar Gogada Cc: linux-pci, linux-kernel, bhelgaas, rgummal, linux-pci-owner On 2018-08-09 20:27, Bharat Kumar Gogada wrote: > As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages > will be forwarded from the secondary interface to the primary > interface, > if the SERR# Enable bit in the Bridge Control register is set. > Currently PCI_BRIDGE_CTL_SERR is being enabled only in > ACPI flow. > This patch enables PCI_BRIDGE_CTL_SERR for Type-1 PCI device. > > Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> > --- > drivers/pci/pcie/aer.c | 23 +++++++++++++++++++++++ > 1 files changed, 23 insertions(+), 0 deletions(-) > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c > index a2e8838..4fb0d24 100644 > --- a/drivers/pci/pcie/aer.c > +++ b/drivers/pci/pcie/aer.c > @@ -343,6 +343,20 @@ int pci_enable_pcie_error_reporting(struct pci_dev > *dev) > if (!dev->aer_cap) > return -EIO; > > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { > + u16 control; > + > + /* > + * A Type-1 PCI bridge will not forward ERR_ messages coming > + * from an endpoint if SERR# forwarding is not enabled. > + */ > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); > + if (!(control & PCI_BRIDGE_CTL_SERR)) { > + control |= PCI_BRIDGE_CTL_SERR; > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); > + } > + } > + > return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, > PCI_EXP_AER_FLAGS); > } > EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting); > @@ -352,6 +366,15 @@ int pci_disable_pcie_error_reporting(struct > pci_dev *dev) > if (pcie_aer_get_firmware_first(dev)) > return -EIO; > > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { > + u16 control; > + > + /* Clear SERR Forwarding */ > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); > + control &= ~PCI_BRIDGE_CTL_SERR; > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); > + } > + > return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, > PCI_EXP_AER_FLAGS); > } Hi Bjorn, I made some comments on patchv1., same I am putting it across here. what about hot-plug case ? should not aer_init() call pci_enable_pcie_error_reporting() for all the downstream pci_dev ? and remove all the calls from drivers.. aer_init will be called for each device (pci_dev) while pciehp does re-enumeration. so probable we might want to call pci_enable_pcie_error_reporting() but that dictates the design where AER framework is taking decision to enable error reporting on behalf of drivers as well. but thats fine I think, if drivers do not want to participate then they have to call pci_disable_pcie_error_reporting explicitly. does this make sense ? ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow 2018-08-09 15:11 ` poza @ 2018-08-24 12:13 ` Bharat Kumar Gogada 2018-09-05 20:10 ` Bjorn Helgaas 1 sibling, 0 replies; 6+ messages in thread From: Bharat Kumar Gogada @ 2018-08-24 12:13 UTC (permalink / raw) To: poza@codeaurora.org Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, bhelgaas@google.com, Ravikiran Gummaluri, linux-pci-owner@vger.kernel.org > Subject: Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow >=20 > On 2018-08-09 20:27, Bharat Kumar Gogada wrote: > > As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages will be > > forwarded from the secondary interface to the primary interface, if > > the SERR# Enable bit in the Bridge Control register is set. > > Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. > > This patch enables PCI_BRIDGE_CTL_SERR for Type-1 PCI device. > > > > Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> > > --- > > drivers/pci/pcie/aer.c | 23 +++++++++++++++++++++++ > > 1 files changed, 23 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c index > > a2e8838..4fb0d24 100644 > > --- a/drivers/pci/pcie/aer.c > > +++ b/drivers/pci/pcie/aer.c > > @@ -343,6 +343,20 @@ int pci_enable_pcie_error_reporting(struct > > pci_dev > > *dev) > > if (!dev->aer_cap) > > return -EIO; > > > > + if (dev->hdr_type =3D=3D PCI_HEADER_TYPE_BRIDGE) { > > + u16 control; > > + > > + /* > > + * A Type-1 PCI bridge will not forward ERR_ messages > coming > > + * from an endpoint if SERR# forwarding is not enabled. > > + */ > > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, > &control); > > + if (!(control & PCI_BRIDGE_CTL_SERR)) { > > + control |=3D PCI_BRIDGE_CTL_SERR; > > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, > control); > > + } > > + } > > + > > return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, > > PCI_EXP_AER_FLAGS); } > > EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting); > > @@ -352,6 +366,15 @@ int pci_disable_pcie_error_reporting(struct > > pci_dev *dev) > > if (pcie_aer_get_firmware_first(dev)) > > return -EIO; > > > > + if (dev->hdr_type =3D=3D PCI_HEADER_TYPE_BRIDGE) { > > + u16 control; > > + > > + /* Clear SERR Forwarding */ > > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, > &control); > > + control &=3D ~PCI_BRIDGE_CTL_SERR; > > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); > > + } > > + > > return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, > > PCI_EXP_AER_FLAGS); > > } >=20 >=20 > Hi Bjorn, >=20 > I made some comments on patchv1., same I am putting it across here. >=20 > what about hot-plug case ? > should not aer_init() call pci_enable_pcie_error_reporting() for all the > downstream pci_dev ? > and remove all the calls from drivers.. > aer_init will be called for each device (pci_dev) while pciehp does re- > enumeration. > so probable we might want to call pci_enable_pcie_error_reporting() but > that dictates the design where AER framework is taking decision to enable > error reporting on behalf of drivers as well. > but thats fine I think, if drivers do not want to participate then they h= ave to > call pci_disable_pcie_error_reporting explicitly. > does this make sense ? >=20 Hi Bjorn, Can you please comment on this. Bharat ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow 2018-08-09 15:11 ` poza 2018-08-24 12:13 ` Bharat Kumar Gogada @ 2018-09-05 20:10 ` Bjorn Helgaas 2018-09-10 6:10 ` poza 1 sibling, 1 reply; 6+ messages in thread From: Bjorn Helgaas @ 2018-09-05 20:10 UTC (permalink / raw) To: poza Cc: Bharat Kumar Gogada, linux-pci, linux-kernel, bhelgaas, rgummal, linux-pci-owner On Thu, Aug 09, 2018 at 08:41:27PM +0530, poza@codeaurora.org wrote: > On 2018-08-09 20:27, Bharat Kumar Gogada wrote: > > As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages > > will be forwarded from the secondary interface to the primary interface, > > if the SERR# Enable bit in the Bridge Control register is set. > > Currently PCI_BRIDGE_CTL_SERR is being enabled only in > > ACPI flow. > > This patch enables PCI_BRIDGE_CTL_SERR for Type-1 PCI device. > > > > Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> > > --- > > drivers/pci/pcie/aer.c | 23 +++++++++++++++++++++++ > > 1 files changed, 23 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c > > index a2e8838..4fb0d24 100644 > > --- a/drivers/pci/pcie/aer.c > > +++ b/drivers/pci/pcie/aer.c > > @@ -343,6 +343,20 @@ int pci_enable_pcie_error_reporting(struct pci_dev > > *dev) > > if (!dev->aer_cap) > > return -EIO; > > > > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { > > + u16 control; > > + > > + /* > > + * A Type-1 PCI bridge will not forward ERR_ messages coming > > + * from an endpoint if SERR# forwarding is not enabled. > > + */ > > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); > > + if (!(control & PCI_BRIDGE_CTL_SERR)) { > > + control |= PCI_BRIDGE_CTL_SERR; > > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); > > + } > > + } > > + > > return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, > > PCI_EXP_AER_FLAGS); > > } > > EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting); > > @@ -352,6 +366,15 @@ int pci_disable_pcie_error_reporting(struct pci_dev > > *dev) > > if (pcie_aer_get_firmware_first(dev)) > > return -EIO; > > > > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { > > + u16 control; > > + > > + /* Clear SERR Forwarding */ > > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); > > + control &= ~PCI_BRIDGE_CTL_SERR; > > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); > > + } > > + > > return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, > > PCI_EXP_AER_FLAGS); > > } > > > Hi Bjorn, > > I made some comments on patchv1., same I am putting it across here. > > what about hot-plug case ? > should not aer_init() call pci_enable_pcie_error_reporting() for all > the downstream pci_dev ? > and remove all the calls from drivers.. > aer_init will be called for each device (pci_dev) while pciehp does > re-enumeration. > so probable we might want to call pci_enable_pcie_error_reporting() > but that dictates the design where AER framework is taking decision to > enable error reporting on behalf of drivers as well. > but thats fine I think, if drivers do not want to participate then they have > to call pci_disable_pcie_error_reporting explicitly. > does this make sense ? I just replied to the original patch; sorry, I forgot to add you to the cc list. Bharat, when people respond to your v<N> patch, can you please add them (and anybody else *they* added) to the cc list when you post your v<N+1> patch? If we set PCI_BRIDGE_CTL_SERR in the pci_configure_device() path, would that address your comments? There's still a separate question of where and how we should configure the error bits in PCI_EXP_DEVCTL (currently done in pci_enable_pcie_error_reporting()). Bjorn ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow 2018-09-05 20:10 ` Bjorn Helgaas @ 2018-09-10 6:10 ` poza 0 siblings, 0 replies; 6+ messages in thread From: poza @ 2018-09-10 6:10 UTC (permalink / raw) To: Bjorn Helgaas Cc: Bharat Kumar Gogada, linux-pci, linux-kernel, bhelgaas, rgummal, linux-pci-owner On 2018-09-06 01:40, Bjorn Helgaas wrote: > On Thu, Aug 09, 2018 at 08:41:27PM +0530, poza@codeaurora.org wrote: >> On 2018-08-09 20:27, Bharat Kumar Gogada wrote: >> > As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages >> > will be forwarded from the secondary interface to the primary interface, >> > if the SERR# Enable bit in the Bridge Control register is set. >> > Currently PCI_BRIDGE_CTL_SERR is being enabled only in >> > ACPI flow. >> > This patch enables PCI_BRIDGE_CTL_SERR for Type-1 PCI device. >> > >> > Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> >> > --- >> > drivers/pci/pcie/aer.c | 23 +++++++++++++++++++++++ >> > 1 files changed, 23 insertions(+), 0 deletions(-) >> > >> > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c >> > index a2e8838..4fb0d24 100644 >> > --- a/drivers/pci/pcie/aer.c >> > +++ b/drivers/pci/pcie/aer.c >> > @@ -343,6 +343,20 @@ int pci_enable_pcie_error_reporting(struct pci_dev >> > *dev) >> > if (!dev->aer_cap) >> > return -EIO; >> > >> > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { >> > + u16 control; >> > + >> > + /* >> > + * A Type-1 PCI bridge will not forward ERR_ messages coming >> > + * from an endpoint if SERR# forwarding is not enabled. >> > + */ >> > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); >> > + if (!(control & PCI_BRIDGE_CTL_SERR)) { >> > + control |= PCI_BRIDGE_CTL_SERR; >> > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); >> > + } >> > + } >> > + >> > return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, >> > PCI_EXP_AER_FLAGS); >> > } >> > EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting); >> > @@ -352,6 +366,15 @@ int pci_disable_pcie_error_reporting(struct pci_dev >> > *dev) >> > if (pcie_aer_get_firmware_first(dev)) >> > return -EIO; >> > >> > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { >> > + u16 control; >> > + >> > + /* Clear SERR Forwarding */ >> > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); >> > + control &= ~PCI_BRIDGE_CTL_SERR; >> > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); >> > + } >> > + >> > return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, >> > PCI_EXP_AER_FLAGS); >> > } >> >> >> Hi Bjorn, >> >> I made some comments on patchv1., same I am putting it across here. >> >> what about hot-plug case ? >> should not aer_init() call pci_enable_pcie_error_reporting() for all >> the downstream pci_dev ? >> and remove all the calls from drivers.. >> aer_init will be called for each device (pci_dev) while pciehp does >> re-enumeration. >> so probable we might want to call pci_enable_pcie_error_reporting() >> but that dictates the design where AER framework is taking decision to >> enable error reporting on behalf of drivers as well. >> but thats fine I think, if drivers do not want to participate then >> they have >> to call pci_disable_pcie_error_reporting explicitly. >> does this make sense ? > > I just replied to the original patch; sorry, I forgot to add you to > the cc list. Bharat, when people respond to your v<N> patch, can you > please add them (and anybody else *they* added) to the cc list when > you post your v<N+1> patch? > > If we set PCI_BRIDGE_CTL_SERR in the pci_configure_device() path, > would that address your comments? yes, that should do. > > There's still a separate question of where and how we should configure > the error bits in PCI_EXP_DEVCTL (currently done in > pci_enable_pcie_error_reporting()). > > Bjorn ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow 2018-08-09 14:57 [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow Bharat Kumar Gogada 2018-08-09 15:11 ` poza @ 2018-09-05 20:04 ` Bjorn Helgaas 1 sibling, 0 replies; 6+ messages in thread From: Bjorn Helgaas @ 2018-09-05 20:04 UTC (permalink / raw) To: Bharat Kumar Gogada; +Cc: linux-pci, linux-kernel, bhelgaas, rgummal On Thu, Aug 09, 2018 at 08:27:37PM +0530, Bharat Kumar Gogada wrote: > As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages > will be forwarded from the secondary interface to the primary interface, > if the SERR# Enable bit in the Bridge Control register is set. > Currently PCI_BRIDGE_CTL_SERR is being enabled only in > ACPI flow. > This patch enables PCI_BRIDGE_CTL_SERR for Type-1 PCI device. I agree this is a problem. We should not depend on how firmware set PCI_BRIDGE_CTL_SERR. I would prefer to set it in the pci_configure_device() path so we always do it the same way for every device, independent of whether AER is enabled. Some platform firmware must already enable PCI_BRIDGE_CTL_SERR, even though it can't know whether the OS will support AER, so it should be safe for the OS to enable it unconditionally. The code in program_hpp_type0() that sets PCI_BRIDGE_CTL_SERR is based on 40abb96c51bb ("[PATCH] pciehp: Fix programming hotplug parameters") [1], but I think it is incorrect. ACPI v6.0, sec 6.2.9.1, (_HPX PCI Setting Record) says: If the hot plug device includes bridge(s) in the hierarchy, the above settings apply to the primary side (command register) of the hot plugged bridge(s). The settings for the secondary side of the bridge(s) (Bridge Control Register) are assumed to be provided by the bridge driver. Sec 6.2.8 (for the old _HPP method) doesn't contain that text, but it has the same description of the contents: Enable SERR When set to 1, indicates that action must be performed to enable SERR in the command register. Both sections talk about enabling SERR in the *command* register (not the bridge control register) and the _HPX section is explicit about the fact that "Enable SERR" does not apply to the bridge control register. So I think pci_configure_device() should unconditionally set PCI_BRIDGE_CTL_SERR for all bridge devices. And we should remove the corresponding code from program_hpp_type0(). [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=40abb96c51bb > Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> > --- > drivers/pci/pcie/aer.c | 23 +++++++++++++++++++++++ > 1 files changed, 23 insertions(+), 0 deletions(-) > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c > index a2e8838..4fb0d24 100644 > --- a/drivers/pci/pcie/aer.c > +++ b/drivers/pci/pcie/aer.c > @@ -343,6 +343,20 @@ int pci_enable_pcie_error_reporting(struct pci_dev *dev) > if (!dev->aer_cap) > return -EIO; > > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { > + u16 control; > + > + /* > + * A Type-1 PCI bridge will not forward ERR_ messages coming > + * from an endpoint if SERR# forwarding is not enabled. > + */ > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); > + if (!(control & PCI_BRIDGE_CTL_SERR)) { > + control |= PCI_BRIDGE_CTL_SERR; > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); > + } > + } > + > return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_AER_FLAGS); > } > EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting); > @@ -352,6 +366,15 @@ int pci_disable_pcie_error_reporting(struct pci_dev *dev) > if (pcie_aer_get_firmware_first(dev)) > return -EIO; > > + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) { > + u16 control; > + > + /* Clear SERR Forwarding */ > + pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &control); > + control &= ~PCI_BRIDGE_CTL_SERR; > + pci_write_config_word(dev, PCI_BRIDGE_CONTROL, control); > + } > + > return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, > PCI_EXP_AER_FLAGS); > } > -- > 1.7.1 > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-09-10 6:10 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-08-09 14:57 [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow Bharat Kumar Gogada 2018-08-09 15:11 ` poza 2018-08-24 12:13 ` Bharat Kumar Gogada 2018-09-05 20:10 ` Bjorn Helgaas 2018-09-10 6:10 ` poza 2018-09-05 20:04 ` Bjorn Helgaas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).