kernel/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/base.c, branch linux-4.17.y

drm/nouveau/secboot: allow to boot multiple falcons

2017-04-06T04:39:03Z

Change the secboot and msgqueue interfaces to take a mask of falcons to reset instead of a single falcon. The GP10B firmware interface requires FECS and GPCCS to be booted in a single firmware command. For firmwares that only support single falcon boot, it is trivial to loop over the mask and boot each falcons individually. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

drm/nouveau/secboot: support for different load and unload falcons

2017-03-07T07:05:13Z

On some secure boot instances (e.g. gp10x) the load and unload blobs do not run on the same falcon. Support this case by introducing a new member to the ACR structure and making related functions take the falcon to use as an argument instead of assuming the boot falcon is to be used. The rule is that the load blob can be run on either the SEC or PMU falcons, but the unload blob must be always run on PMU. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

drm/nouveau/secboot: support running ACR on SEC

2017-03-07T07:05:13Z

Add support for running the ACR binary on the SEC falcon. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

drm/nouveau/secboot: abstract LS firmware loading functions

2017-02-17T05:14:32Z

The WPR and LSB headers, used to generate the LS blob, may have a different layout and sizes depending on the driver version they come from. Abstract them and confine their use to driver-specific code. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

drm/nouveau/secboot: reorganize into more files

2017-02-17T05:14:31Z

Split the act of building the ACR blob from firmware files from the rest of the (chip-dependent) secure boot logic. ACR logic is moved into acr_rxxx.c files, where rxxx corresponds to the compatible release of the NVIDIA driver. At the moment r352 and r361 are supported since firmwares have been released for these versions. Some abstractions are added on top of r352 so r361 can easily be implemented on top of it by just overriding a few hooks. This split makes it possible and easy to reuse the same ACR version on different chips. It also hopefully makes the code much more readable as the different secure boot logics are separated. As more chips and firmware versions will be supported, this is a necessity to not get lost in code that is already quite complex. This is a big commit, but it essentially moves things around (and split the nvkm_secboot structure into two, nvkm_secboot and nvkm_acr). Code semantics should not be affected. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

drm/nouveau/secboot: rename init() hook to oneinit()

2017-02-17T05:14:31Z

The init() hook is called by the subdev's oneinit(). Rename it accordingly to avoid confusion about the lifetime of objects allocated in it. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

drm/nouveau/secboot: remove nvkm_secboot_start()

2017-02-17T05:14:31Z

Since GR has moved to using the falcon library to start the falcons, this function is not needed anymore. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

drm/nouveau/secboot: use falcon library

2017-02-17T05:14:31Z

Use the falcon library functions in secure boot. This removes a lot of code and makes the secure boot flow easier to understand as no register is directly accessed. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

drm/nouveau/secboot: fix functions definitions

2017-02-17T05:14:31Z

These functions should use the nvkm_secboot_falcon enum. Fix this. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs

drm/nouveau/secboot: lazy-load firmware and be more resilient

2016-07-14T01:53:25Z

Defer the loading of firmware files to the chip-specific part of secure boot. This allows implementations to retry loading firmware if the first attempt failed ; for the GM200 implementation, this happens when trying to reset a falcon, typically in reaction to GR init. Firmware loading may fail for a variety of reasons, such as the filesystem where they reside not being ready at init time. This new behavior allows GR to be initialized the next time we try to use it if the firmware has become available. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs