similar to: [PATCH -next] drm/nouveau/secboot/gm20b: fix the error return code in gm20b_secboot_tegra_read_wpr()

From: Thierry Reding <treding at nvidia.com> The GPUs found on Tegra SoCs have registers that can be used to read the WPR configuration. Use these registers instead of reaching into the memory controller's register space to read the same information. Signed-off-by: Thierry Reding <treding at nvidia.com> --- .../drm/nouveau/nvkm/subdev/secboot/gm200.h | 2 +-

On Tue, Sep 17, 2019 at 01:49:57PM +1000, Ben Skeggs wrote: > On Tue, 17 Sep 2019 at 01:04, Thierry Reding <thierry.reding at gmail.com> wrote: > > > > From: Thierry Reding <treding at nvidia.com> > > > > The GPUs found on Tegra SoCs have registers that can be used to read the > > WPR configuration. Use these registers instead of reaching into the >

On Tue, 17 Sep 2019 at 01:04, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The GPUs found on Tegra SoCs have registers that can be used to read the > WPR configuration. Use these registers instead of reaching into the > memory controller's register space to read the same information. > >

If 'ioremap()' returns 0, 'gm20b_tegra_read_wpr()' will return 0 as well, which means success. Return -ENOMEM instead Signed-off-by: Christophe JAILLET <christophe.jaillet at wanadoo.fr> --- Not sure that -ENOMEM is the best value. I've taken it because it is often used in such a case. --- drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c | 2 +- 1 file changed, 1

From: Dan Carpenter <dan.carpenter at oracle.com> [ Upstream commit 3613a9bea95a1470dd42e4ed1cc7d86ebe0a2dc0 ] We accidentally set "psb" which is a no-op instead of "*psb" so it generates a static checker warning. We should probably set it before the first error return so that it's always initialized. Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add

From: Dan Carpenter <dan.carpenter at oracle.com> [ Upstream commit 3613a9bea95a1470dd42e4ed1cc7d86ebe0a2dc0 ] We accidentally set "psb" which is a no-op instead of "*psb" so it generates a static checker warning. We should probably set it before the first error return so that it's always initialized. Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add

From: Dan Carpenter <dan.carpenter at oracle.com> [ Upstream commit 3613a9bea95a1470dd42e4ed1cc7d86ebe0a2dc0 ] We accidentally set "psb" which is a no-op instead of "*psb" so it generates a static checker warning. We should probably set it before the first error return so that it's always initialized. Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add

From: Dan Carpenter <dan.carpenter at oracle.com> [ Upstream commit 3613a9bea95a1470dd42e4ed1cc7d86ebe0a2dc0 ] We accidentally set "psb" which is a no-op instead of "*psb" so it generates a static checker warning. We should probably set it before the first error return so that it's always initialized. Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add

We accidentally set "psb" which is a no-op instead of "*psb" so it generates a static checker warning. We should probably set it before the first error return so that it's always initialized. Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add secure boot support") Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Static analysis. I'm

Hello Alexandre Courbot, The patch 923f1bd27bf1: "drm/nouveau/secboot/gm20b: add secure boot support" from Feb 24, 2016, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c:129 gm20b_secboot_new() warn: did you mean to set '*psb' instead of 'psb' drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c 103 int 104

This hook can be removed if the function writing the HS descriptor is aware of WPR settings. Let's do that as it allows us to make the ACR descriptor structure private and save some code. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/secboot/gm200.c | 95 ++++++++++++++++++++++++--------- drm/nouveau/nvkm/subdev/secboot/gm20b.c | 11 ----

Hi, in file 'drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c', error handling in 'gm20b_tegra_read_wpr()' seams to be broken. The code used is: mc = ioremap(TEGRA_MC_BASE, 0xd00); if (!mc) { nvkm_error(&sb->subdev, "..."); return PTR_ERR(mc); } so we always return '0', which means success. Best regards, CJ

Secure firmwares provided by NVIDIA will follow the same overall principle, but may slightly differ in format, or not use the same bootloader descriptor even on the same chip. In order to handle this as gracefully as possible, turn the LS firmware functions into hooks that can be overloaded as needed. The current hooks cover the external firmware loading as well as the bootloader descriptor

tegra_fuse_readl() is only defined on Tegra platforms and will break x86 builds. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- This should probably be squashed into the GM20B DFS patch to avoid breaking bisecting. Sorry about this. drm/nouveau/nvkm/subdev/clk/gm20b.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/subdev/clk/gm20b.c

From: Thierry Reding <treding at nvidia.com> The low-level Falcon bootstrapping callbacks are expected to return 0 on success or a negative error code on failure. However, the implementation on Tegra returns the ID or mask of the Falcons that were bootstrapped on success, thus breaking the calling code, which treats this as failure. Fix this by making sure we only return 0 or a negative

On Sat, 30 May 2020 at 19:42, Dinghao Liu <dinghao.liu at zju.edu.cn> wrote: > > When gk20a_clk_ctor() returns an error code, pointer "clk" > should be released. It's the same when gm20b_clk_new() > returns from elsewhere following this call. This shouldn't be necessary. If a subdev constructor fails, and returns a pointer, the core will call the destructor to

When gk20a_clk_ctor() returns an error code, pointer "clk" should be released. It's the same when gm20b_clk_new() returns from elsewhere following this call. Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

gm20b's FB has the same capabilities as gm200, minus the ability to allocate RAM. Create a device that reflects this instead of re-using the gk20a device which may be incorrect. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/include/nvkm/subdev/fb.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 2 +- drm/nouveau/nvkm/subdev/fb/Kbuild | 1 +

On 4.6, probing GM20B will freeze the system because of a missing clock that Nouveau must also enable. Since the DT bindings for this clock did not make it in time for 4.6, disable it for now. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- Ben, sorry for that, but could you take this for one of the next -rc? I will re-enable GM20B once the DT bindings have landed. Thanks!

The msgqueue pointer validity should be checked by its owner, not by the msgqueue code itself to avoid this situation. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> Reported-by: Julia Lawall <julia.lawall at lip6.fr> --- drm/nouveau/nvkm/engine/sec2/base.c | 7 +++++++ drm/nouveau/nvkm/falcon/msgqueue.c | 5 ++--- drm/nouveau/nvkm/subdev/pmu/gm20b.c | 6 ++++++ 3 files