[Nouveau] [PATCH 0/4] secboot: be more resilient on errors

[Alexandre Courbot]

This series fixes two cases where behavior on secure boot errors could be
improved:

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(-)

-- 
2.8.3