[Nouveau] [PATCH 0/4] secboot: be more resilient on errors
acourbot at nvidia.com
Wed Jun 8 08:32:37 UTC 2016
This series fixes two cases where behavior on secure boot errors could be
1) Patch 2 propages secure-boot errors from GR init, making sure initialization
fails as it should. Failure to do so results in a black screen during boot,
as reported in FD bug 94990.
2) Patches 3-4 make the absence of required secure firmware files a non-fatal
error. The previous behavior was to give up the whole driver init altogether.
Now users can at least enjoy a display even if they are missing the firmware
files. On top of that, firmware loading is re-attempted the next time a
secure boot function is invoked, also addressing the case where firmware is
not available at the time of boot (the first GR init attempt will fail, but
the next one will succeed provided the files are now available).
Ben, I know we discussed solving problem 2) by moving firmware loading into the
secboot constructor, but this is impossible due to the fact firmware loading
requires the creation of gpuobj, a feature that is not available at that time.
For this reason I have adopted this lazy and actually more resilient strategy.
Alexandre Courbot (4):
secboot: fix kerneldoc for secure boot structures
gr/gf100: handle secure boot errors
secboot/gm200: make firmware loading re-callable
secboot: lazy-load firmware and be more resilient
drm/nouveau/nvkm/engine/gr/gf100.c | 10 ++++-
drm/nouveau/nvkm/subdev/secboot/base.c | 9 +----
drm/nouveau/nvkm/subdev/secboot/gm200.c | 72 ++++++++++++++++++++++++---------
drm/nouveau/nvkm/subdev/secboot/gm20b.c | 54 ++++++++++++-------------
drm/nouveau/nvkm/subdev/secboot/priv.h | 18 ++++++---
5 files changed, 102 insertions(+), 61 deletions(-)
More information about the Nouveau