Patch Set 14:

Patch Set 14:

So have we gone from wanting to not assign resources for certain devices to not assigning resources for almost all devices unless someone explicitly changes the code?

1. I don't think that was our original problem. At least for USB4/thunderbolt there's a finite set of viddids we can purposefully not allocate resources for.

I.e. a blacklist? That actually looks more complex to me than this current fairly simple solution.

What if I express what you just said a little differently?

We are saying that for certain select mainboards, where such a capability is of interest, we can enable letting the payload do almost all the work of PCI configuration.

In that case, for those mainboards, yes, we can skip just about all devices, and this is something several companies would like to have. They've expressed interest at OSFC, on the coreboot telecon, on the mailing list, to me personally, and in this CL discussion.

We're not claiming this approach works for everything. Then again, we know the current system is not working for everything either, and as Jeremy points out, there are problems coming our way; a general solution that works for all payloads seems increasingly unlikely; and, even if likely, starts to look pretty complicated.

The jury is still out on this current approach; people are supposed to be reporting back to me with some results on real hardware but I have not heard anything yet.

I would say what you describe, Ron, is requirement #3: Opt out all resource assignment. I am fairly certain that with some of the existing chipsets and supporting code this won't work without adding additional hacks/changes.

The addition of #3 definitely doesn't solve the cases Chrome OS would need. I'm trying to understand the superset of people's desires. Jeremy's description of his usage seemed to fall into #1 and #2, but your request is unique from what I have read.

FWIW, I think it's important that the post coreboot boundary is effectively an OS. Getting all the hardware initialized does take needing to access registers, etc, even if things don't look like pci standard. So are we going to undo that programming so the payload/OS can reprogram BARs? It would be the simplest from a coding perspective since it's apply this policy to every found pci device.

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: 14
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: Patrick Rudolph <siro@das-labor.org>
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: Mon, 04 Nov 2019 17:13:40 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment