Re: [PATCH v2 13/15] phy: qcom-qmp-pcie: add support for pipediv2 clock

Dmitry Baryshkov
2022-10-20T10:53:12Z

On 20/10/2022 13:49, Johan Hovold wrote:
> On Thu, Oct 20, 2022 at 12:28:14PM +0300, Dmitry Baryshkov wrote:
>> On 20/10/2022 12:05, Johan Hovold wrote:
>
>>> Here's your example diff inline:
>
>>> @@ -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).
>
>>> 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