From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Olof Johansson <olof@lixom.net>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Keith Busch <keith.busch@intel.com>,
linux-pci@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI/DPC: Add pcie_ports=dpc-native parameter to bring back old behavior
Date: Thu, 7 Nov 2019 14:05:26 -0800 [thread overview]
Message-ID: <43b431b6-f544-f9f0-d6f3-f383d7b882b9@linux.intel.com> (raw)
In-Reply-To: <CAOesGMhdAUKj9f0=sVwH7kffr=P-LqWWqKxKK3N3e0MpcjLExw@mail.gmail.com>
On 11/7/19 12:09 PM, Olof Johansson wrote:
> On Thu, Nov 7, 2019 at 12:02 PM Kuppuswamy Sathyanarayanan
> <sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
>> Hi,
>>
>> On 10/25/19 1:20 PM, Bjorn Helgaas wrote:
>>> On Wed, Oct 23, 2019 at 12:22:05PM -0700, Olof Johansson wrote:
>>>> In commit eed85ff4c0da7 ("PCI/DPC: Enable DPC only if AER is available"),
>>>> the behavior was changed such that native (kernel) handling of DPC
>>>> got tied to whether the kernel also handled AER. While this is what
>>>> the standard recommends, there are BIOSes out there that lack the DPC
>>>> handling since it was never required in the past.
>>> Some systems do not grant OS control of AER via _OSC. I guess the
>>> problem is that on those systems, the OS DPC driver used to work, but
>>> after eed85ff4c0da7, it does not. Right?
>> I need some clarification on this issue. Do you mean in these systems,
>> firmware expects OS to handle DPC and AER, but it does not let OS know
>> about it via _OSC ?
> The OS and BIOS both assumed behavior as before eed85ff4c0da7 -- AER
> handled by firmware but DPC handled by kernel.
>
> I.e. a classic case of "Sure, the spec says this, but in reality
> implementations relied on actual behavior", and someone had a
> regression and need a way to restore previous behavior.
Got it. I don't know whether its good to add hacks to support products
that does not follow spec.
But, do you think it would be useful to add some kind of warning message
when this option is
enabled ? May be it could be useful in debugging.
>
> -Olof
>
--
Sathyanarayanan Kuppuswamy
Linux kernel developer
next prev parent reply other threads:[~2019-11-07 22:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 19:22 [PATCH] PCI/DPC: Add pcie_ports=dpc-native parameter to bring back old behavior Olof Johansson
2019-10-24 2:37 ` Keith Busch
2019-10-24 3:45 ` Olof Johansson
2019-10-25 20:20 ` Bjorn Helgaas
2019-11-07 19:59 ` Kuppuswamy Sathyanarayanan
2019-11-07 20:09 ` Olof Johansson
2019-11-07 22:05 ` Kuppuswamy Sathyanarayanan [this message]
2019-11-07 23:59 ` Olof Johansson
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=43b431b6-f544-f9f0-d6f3-f383d7b882b9@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=helgaas@kernel.org \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=olof@lixom.net \
/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 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).