On Mon, Aug 24, 2020 at 05:36:47PM +0800, Tanwar, Rahul wrote:
> On 24/8/2020 4:17 pm, Andy Shevchenko wrote:
> > On Mon, Aug 24, 2020 at 11:36:37AM +0800, Rahul Tanwar wrote:
...
> >> + ret = reset_control_deassert(pc->rst);
> >> + if (ret) {
> >> + if (ret != -EPROBE_DEFER)
> >> + dev_err_probe(dev, ret, "cannot deassert reset control\n");
> >> + return ret;
> >> + }
> > Please, spend a bit of time to understand the changes you are doing. There are
> > already few examples how to use dev_err_probe() properly.
>
> I guess your point is that the check of (ret !- -EPROBE_DEFER) is not needed
> when using dev_err_probe() as it encapsulates it.
It does even more. Look at the existing examples.
> Sorry, i missed it. Will
> fix it. I am not able to find any other missing point after referring to
> two driver examples which uses dev_err_probe() ?
There are three drivers that are using it in Linux Next. All of them utilizing
it correctly, look at them.
> >> + ret = clk_prepare_enable(pc->clk);
> >> + if (ret) {
> >> + dev_err(dev, "failed to enable clock\n");
> >> + return ret;
> >> + }
> >> +
> >> + ret = devm_add_action_or_reset(dev, lgm_pwm_action, pc);
> >> + if (ret)
> >> + return ret;
> > You have also ordering issues here.
> >
> > So, what I can see about implementation is that
> >
> >
> > static void ..._clk_disable(void *data)
> > {
> > clk_disable_unprepare(data);
> > }
> >
> > static int ..._clk_enable(...)
> > {
> > int ret;
> >
> > ret = clk_preare_enable(...);
> > if (ret)
> > return ret;
> > return devm_add_action_or_reset(..., ..._clk_disable);
> > }
> >
> >
> > Similar for reset control.
> >
> > Then in the ->probe() something like this:
> >
> > ret = devm_reset_control_get...;
> > if (ret)
> > return ret;
> >
> > ret = ..._reset_deassert(...);
> > if (ret)
> > return ret;
> >
> > followed by similar section for the clock.
> >
>
> Regarding ordering: In early rounds of review, feedback about ordering was that
> it is recommended to be reverse of the sequence in probe i.e.
> if in probe:
> 1. reset_control_deassert()
> 2. clk_prepare_enable()
> then in remove:
> 1. clk_disable_uprepare()
> 2. reset_control_assert()
>
> That's the reason i added a generic action() which reverses order.
Yes, and my suggestion follows this.
> I understand your suggested way as explained above but not sure if that would
> ensure reverse ordering during unwind.
You have:
devm r1
devm r2
enable r1
enable r2 (and here you have broken error path)
My suggestion has it like this (and no broken error path):
devm r1
enable r1
devm r2
enable r2
--
With Best Regards,
Andy Shevchenko
