> 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()
c
> > 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
> It's possible that we expect an usable clk pointer, though I could not find
> the exact usage yet.
I am curious if another developer would like to add helpful background
information.
> For security, I will release this pointer only on error paths in this
> function.
Do you tend to release o
>
> > For security, I will release this pointer only on error paths in this
> > function.
>
> Do you tend to release objects (which are referenced by pointers)?
>
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(
> > If gk20a_clk_ctor() never returns such an error code,
> > we may 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
> If gk20a_clk_ctor() never returns such an error code,
> we may need not to release this clock object.
Would you like to achieve complete exception handling
also for this function implementation?
Regards,
Markus
___
dri-devel mailing list
dri-devel@lis