linux-kernel - Re: [PATCH v2 3/4] clk: sophgo: Add SG2042 clock generator driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Nov 2023 10:16:56 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Chen Wang <unicorn_wang@...look.com>,
        Chen Wang <unicornxw@...il.com>, aou@...s.berkeley.edu,
        chao.wei@...hgo.com, conor@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, mturquette@...libre.com,
        palmer@...belt.com, paul.walmsley@...ive.com,
        richardcochran@...il.com, robh+dt@...nel.org, sboyd@...nel.org,
        devicetree@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        haijiao.liu@...hgo.com, xiaoguang.xing@...hgo.com,
        guoren@...nel.org, jszhang@...nel.org, inochiama@...look.com,
        samuel.holland@...ive.com
Subject: Re: [PATCH v2 3/4] clk: sophgo: Add SG2042 clock generator driver

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@...look.com>
>>>
>>> Add a driver for the SOPHGO SG2042 clock generator.
>>>
>>> Signed-off-by: Chen Wang <unicorn_wang@...look.com>
>> ...
>>
>>> +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