On Tue, Apr 3, 2018 at 4:16 PM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > [+cc Rafael, linux-acpi] Thanks. > On Mon, Apr 02, 2018 at 05:09:49PM -0600, Keith Busch wrote: >> On Mon, Apr 02, 2018 at 04:23:02PM -0500, Bjorn Helgaas wrote: >> > On Mon, Apr 02, 2018 at 10:21:57AM -0600, Keith Busch wrote: >> > > A DPC port may be configured to send ERR_COR message when the >> > > triggered. This patch enables this feature so additional notification >> > > of the event is possible. >> > >> > Who is the intended consumer of the ERR_COR message? I guess if the >> > root port supports AER, we'll see AER logging when we didn't before? >> > Is that what you mean by "additional notification"? >> > >> > Or, since the DPC ERR_COR implementation note (sec 6.2.10.2) suggests >> > that ERR_COR is primarily intended for use by platform firmware, does >> > this change enable notification via the firmware? If so, how does >> > that work? Does it require the platform to retain control of AER so >> > it can see these events? But if the platform retains AER control, I >> > don't think we'd be enabling DPC in Linux. I'm confused. >> > >> > The similar implementation note in 6.2.10.5 suggests that >> > DL_ACTIVE_ERR_COR is also intended for use by the platform. Should we >> > be setting that for the same reason we're setting >> > PCI_EXP_DPC_CTL_ERR_COR? >> >> I think there are various ways this could play out. I added this to >> the series per a request for future use, but I actually don't have an >> environment where I could test as intended. As I understand, it was >> for platform firmware that may own the root port, but not switches in >> an external enclosure, so the OS would own the DPC control. The ERR_COR >> is to notify firmware so it may note an event in a platform log. > > This picture doesn't make sense to me yet. Per the PCI Firmware spec, > r3.2, sec 4.5.2, we use _OSC to negotiate control over AER (and now > DPC). I think _OSC is only allowed directly under a host bridge > device (PNP0A08 or PNP0A03), and it applies to the entire hierarchy > under the host bridge. > > I don't know how firmware could claim to own AER on a root port, but > not on switches (external or otherwise) below that root port. > > If _OSC says firmware owns AER, we won't touch AER on the root port, > but we also won't touch DPC on switches below the root port. So I > don't see how this change will help. This matches my understanding of that part of the spec. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
