Patch Set 9:
> What's the issue here?

Ron, I enjoyed Jeremy's thorough answer. Yours, not so much.

I'm not trying to be unpleasant. I literally do not understand the objections.

I am talking to companies that don't see a path forward in coreboot without this change, e.g. Jeremy's comment: "The ability to do PCIe resource allocation in the payload will soon become a deciding factor in our ability to continue using and contributing to coreboot."

The question is not changing how coreboot does this function; the question is whether we want coreboot to do it at all. We have found a few cases in a few mainboards where we have to scan a few devices; the mandatory keyword is designed to communicate that fact.

Further, there is interest in seeing how the payload can do some of these functions, as opposed to having the ramstage do it. This is in part because the ramstage is a general purpose stage that accomodates a broad range of payloads, and what it does is not always needed.

If we are seeking the minimal change approach to resolve resource allocation problem (which appears to be *the* vendor request based on the feedback we received so far) changes to ACPI namespace and/or AML seem largely out-of-scope and undesirable.

I'm not sure you are entirely correct on some details, e.g. I've never needed ACPI information when implementing MSI-X in a kernel, just for MSI (which is why we did not bother with MSI in Akaros and Harvey, we went right to MSI-X).

This request is our first attempt at a configurable ramstage. It is a first step along a path. Based on earlier experience, we figure it is best to take this one step at a time, rather than all at once. The minimal PCI is not the only thing we are seeking, it is one of the things we are seeking. In the work of the previous year is was made clear to us that removing the ramstage was not acceptable, and that a configurable ramstage made more sense. So we are trying that. 

> The keyword 'mandatory' sounds very much like a platform property that will end up being copied for each individual mainboard. Well... PCI drivers would be the perfect place to have that instead,

I am not sure we know that. We chose this path as we feel that a device being mandatory is likely to be mainboard-dependent, i.e. how a mainboard uses devices, than a property of the device itself.

All that said, I respect you and Nico very highly; I don't intend to submit this until I have some feeling I'm not misunderstanding what you are telling me. I regret any bad feelings I might have caused.

View Change

To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.

Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I2073d9f8e9297c2b02530821ebb634ea2a5c758e
Gerrit-Change-Number: 36221
Gerrit-PatchSet: 9
Gerrit-Owner: ron minnich <rminnich@gmail.com>
Gerrit-Reviewer: Aaron Durbin <adurbin@chromium.org>
Gerrit-Reviewer: Furquan Shaikh <furquan@google.com>
Gerrit-Reviewer: Jeremy Soller <jeremy@system76.com>
Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki@gmail.com>
Gerrit-Reviewer: Lean Sheng Tan <lean.sheng.tan@intel.com>
Gerrit-Reviewer: Martin Roth <martinroth@google.com>
Gerrit-Reviewer: Nico Huber <nico.h@gmx.de>
Gerrit-Reviewer: Patrick Georgi <pgeorgi@google.com>
Gerrit-Reviewer: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Gerrit-Reviewer: Shelley Chen <shchen@google.com>
Gerrit-Reviewer: Subrata Banik <subrata.banik@intel.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply@coreboot.org>
Gerrit-Reviewer: ron minnich <rminnich@gmail.com>
Gerrit-CC: Paul Menzel <paulepanter@users.sourceforge.net>
Gerrit-Comment-Date: Fri, 25 Oct 2019 20:34:46 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment