On Mon, Aug 24, 2020 at 05:36:47PM +0800, Tanwar, Rahul wrote:

On 24/8/2020 4:17 pm, Andy Shevchenko wrote:

quoted

On Mon, Aug 24, 2020 at 11:36:37AM +0800, Rahul Tanwar wrote:

...

quoted

quoted

+	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.

quoted

quoted

+	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