Messages in this thread | | | Date | Tue, 1 Sep 2020 15:20:54 +0530 | From | Viresh Kumar <> | Subject | Re: [PATCH V2 3/8] drm/msm: Unconditionally call dev_pm_opp_of_remove_table() |
| |
On 01-09-20, 15:15, Rajendra Nayak wrote: > > On 9/1/2020 2:08 PM, Viresh Kumar wrote: > > On 01-09-20, 13:01, Rajendra Nayak wrote: > > > So FWIU, dpu_unbind() gets called even when dpu_bind() fails for some reason. > > > > Ahh, I see. > > > > > I tried to address that earlier [1] which I realized did not land. > > > > I don't think that patch was required, as you can call > > dev_pm_opp_put_clkname() multiple times and it will return without any > > errors/crash. > > We did see a crash (Sai had reported it), perhaps with dsi [1] and not this > driver. But it was the same scenario that was possible here as well, which is > dev_pm_opp_put_clkname() getting called without dev_pm_opp_set_clkname() > being done. I think we ended up passing a NULL as opp_table in that case > and the function tries de-referencing it.
Heh, yeah I did miss that stupid thing :(
> > > > > But with these changes > > > it will be even more broken unless we identify if we failed dpu_bind() before > > > adding the OPP table, while adding it, or all went well with opps and handle things > > > accordingly in dpu_unbind. > > > > Maybe not as dev_pm_opp_of_remove_table() can be called multiple times > > as well without any errors or crash. > > Can it be called without the driver ever doing a dev_pm_opp_of_add_table()?
Yes, as we will fail to find the OPP device in that case with -ENODEV and so won't even print a warning.
Also if the OPP table was previously added as a response to dev_pm_opp_set_clkname(), then we won't free it as well. So yes, it should work just fine.
-- viresh
| |