On 20/10/2022 13:49, Johan Hovold wrote:

On Thu, Oct 20, 2022 at 12:28:14PM +0300, Dmitry Baryshkov wrote:

quoted

On 20/10/2022 12:05, Johan Hovold wrote:

quoted

quoted

Here's your example diff inline:

quoted

quoted

@@ -2206,12 +2207,17 @@ static int qmp_pcie_parse_dt_legacy(struct qmp_pcie *qmp, struct device_node *np
   		}
   	}
   
-	qmp->pipe_clk = devm_get_clk_from_child(dev, np, NULL);
-	if (IS_ERR(qmp->pipe_clk)) {
-		return dev_err_probe(dev, PTR_ERR(qmp->pipe_clk),
+	clk = devm_get_clk_from_child(dev, np, NULL);
+	if (IS_ERR(clk)) {
+		return dev_err_probe(dev, PTR_ERR(clk),
   				     "failed to get pipe clock\n");
   	}
   
+	qmp->num_pipe_clks = 1;
+	qmp->pipe_clks = devm_kcalloc(dev, qmp->num_pipe_clks,
+				      sizeof(*qmp->pipe_clks), GFP_KERNEL);
+	qmp->pipe_clks[0].clk = clk;

So here you're poking at bulk API internals and forgot to set the id
string, which the implementation uses.

I didn't forget, I just skipped setting it. Hmm. I thought that it is
used only for clk_bulk_get. But after checking, it seems it's also used
for error messages. Mea culpa.

But it's not that I was poking into the internals. These items are in
the public header.

My point is that you're not using the bulk API as it was intended (e.g.
with clk_bulk_get()) and you risk running into issues like the above.

And looking up the actual clock name for this is overkill, even in the
case were it is provided, so we'd need to set it unconditionally to
"pipe" (which is fine).

quoted

quoted

For reasons like this, and the fact that will likely never have a third
pipe clock, I'm reluctant to using the bulk API.

Let's resort to the maintainer opinion then.

I'll take another look at it too.

Thanks!

-- 
With best wishes
Dmitry