Displaying 3 results from an estimated 3 matches for "nvkm_notify_init".
Did you mean:
nvif_notify_init
2020 May 31
2
drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new()
> > I just found that clk is referenced by pclk in this function. When clk is freed,
> > pclk will be allocated in gm20b_clk_new_speedo0(). Thus we should not release clk
> > in this function and there is no bug here.
>
> Can there be a need to release a clock object after a failed gk20a_clk_ctor() call?
>
I think this mainly depends on pclk pointer. It seems that the
2020 May 31
1
drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new()
...need not to release this clock object.
>
> Would you like to achieve complete exception handling
> also for this function implementation?
>
It seems that it's possible to get -ENOMEM from gk20a_clk_ctor().
The call chain is as follows:
gk20a_clk_ctor() <- nvkm_clk_ctor() <- nvkm_notify_init()
When nvkm_notify_init() returns -ENOMEM, all of its callers (and
callers of callers) will be influenced if there is a failed
kzalloc inside which.
In this case, maybe we should check the return value of
gk20a_clk_ctor() and release clk if it returns -ENOMEM.
And many other functions also ha...
2017 Nov 17
35
[PATCH 00/32] Updated State of my clk patches
Last update here: https://lists.freedesktop.org/archives/nouveau/2017-September/028848.html
Basically big cleanup, reordering, simplifications and some renaming to make
the code easier to read and to review. I also moved some bugfixes to the front
so they can be merged prior the other patches.
There was also a bug related to the therm daemon triggering a pstate change
leading to PMU lockups,