On 27/11/2023 09:07, Chen Wang wrote:
>
> On 2023/11/27 15:12, Krzysztof Kozlowski wrote:
>> On 27/11/2023 02:15, Chen Wang wrote:
>>> From: Chen Wang <unicorn_wang@xxxxxxxxxxx>
>>>
>>> Add a driver for the SOPHGO SG2042 clock generator.
>>>
>>> Signed-off-by: Chen Wang <unicorn_wang@xxxxxxxxxxx>
>> ...
>>
>>> +static void __init sg2042_clk_init(struct device_node *node)
>>> +{
>>> + struct sg2042_clk_data *clk_data = NULL;
>>> + int i, ret = 0;
>>> + int num_clks = 0;
>>> +
>>> + num_clks = ARRAY_SIZE(sg2042_pll_clks) +
>>> + ARRAY_SIZE(sg2042_div_clks) +
>>> + ARRAY_SIZE(sg2042_gate_clks) +
>>> + ARRAY_SIZE(sg2042_mux_clks);
>>> + if (num_clks == 0) {
>>> + ret = -EINVAL;
>>> + goto error_out;
>>> + }
>>> +
>>> + ret = sg2042_clk_init_clk_data(node, num_clks, &clk_data);
>>> + if (ret < 0)
>>> + goto error_out;
>>> +
>>> + ret = sg2042_clk_register_plls(clk_data, sg2042_pll_clks,
>>> + ARRAY_SIZE(sg2042_pll_clks));
>>> + if (ret)
>>> + goto cleanup;
>>> +
>>> + ret = sg2042_clk_register_divs(clk_data, sg2042_div_clks,
>>> + ARRAY_SIZE(sg2042_div_clks));
>>> + if (ret)
>>> + goto cleanup;
>>> +
>>> + ret = sg2042_clk_register_gates(clk_data, sg2042_gate_clks,
>>> + ARRAY_SIZE(sg2042_gate_clks));
>>> + if (ret)
>>> + goto cleanup;
>>> +
>>> + ret = sg2042_clk_register_muxs(clk_data, sg2042_mux_clks,
>>> + ARRAY_SIZE(sg2042_mux_clks));
>>> + if (ret)
>>> + goto cleanup;
>>> +
>>> + for (i = 0; i < num_clks; i++)
>>> + dbg_info("provider [%d]: %s\n", i, clk_hw_get_name(clk_data->onecell_data.hws[i]));
>>> + ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, &clk_data->onecell_data);
>>> + if (ret)
>>> + goto cleanup;
>>> +
>>> + return;
>>> +
>>> +cleanup:
>>> + for (i = 0; i < num_clks; i++) {
>>> + if (clk_data->onecell_data.hws[i] != NULL)
>>> + clk_hw_unregister(clk_data->onecell_data.hws[i]);
>>> + }
>>> + kfree(clk_data);
>>> +
>>> +error_out:
>>> + pr_err("%s failed error number %d\n", __func__, ret);
>>> +}
>>> +
>>> +CLK_OF_DECLARE(sg2042_clk, "sophgo,sg2042-clkgen", sg2042_clk_init);
>> No, this should be platform device. It's a child of another device, so
>> you cannot use other way of init ordering.
>
> hi, Krzysztof,
>
> Thanks for your review.
>
> I don't quite understand your opinion. Do you mean CLK_OF_DECLARE is
> only used for platform device so it can not be use here? But I think
No, I meant you mix init ordering: you depend now on syscon earlier
initcall than CLK_OF_DECLARE. Do you remember which one is first? If
anything changes here, your driver is broken. There is no dependency, no
probe deferral.
> this driver is still for platform device though I move the clock
> controller node as a child of the system contoller node. System
> controller node is just a block of registers which are used to control
> some other platform devices ,such as clock controller, reset controller
> and pin controller for this SoC.
>
> And I also see other similar code in kernel, for example:
> drivers/clk/clk-k210.c.
>
> And I'm confused by your input "so you cannot use other way of init
> ordering." Do you mean "so you CAN use other way of init ordering"?
No, I meant you cannot. If you want to use syscon, then your driver
should be a proper driver. Therefore add a driver.
> What's the other way of init ordering do you mean?
The one coming not from initcalls but driver model.
Best regards,
Krzysztof
