Re: [PATCH v5 2/2] clk: samsung: add initial exynos7870 clock driver

[Krzysztof Kozlowski <krzk@kernel.org>]

On 05/03/2025 21:14, Krzysztof Kozlowski wrote:
> On 04/03/2025 19:16, Stephen Boyd wrote:
>> Quoting Kaustabh Chakraborty (2025-02-28 19:57:13)
>>> diff --git a/drivers/clk/samsung/clk-exynos7870.c b/drivers/clk/samsung/clk-exynos7870.c
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..2ec4a4e489be30bd1cd2e6deac006bb8ac5bdc57
>>> --- /dev/null
>>> +++ b/drivers/clk/samsung/clk-exynos7870.c
>>> @@ -0,0 +1,1830 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
>>> + * Author: Kaustabh Chakraborty <kauschluss@disroot.org>
>>> + *
>>> + * Common Clock Framework support for Exynos7870.
>>> + */
>>> +
>>> +#include <linux/clk.h>
>>
>> Please remove this include as this is a clk provider and not a clk
>> consumer.
> 
> 
> I fixed it up for all drivers.
> 
>>
>>> +#include <linux/clk-provider.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/platform_device.h>
>>> +
>>> +#include <dt-bindings/clock/samsung,exynos7870-cmu.h>
>>> +
>>> +#include "clk.h"
>>> +#include "clk-exynos-arm64.h"
>>> +
>>> +/*
>>> + * Register offsets for CMU_MIF (0x10460000)
>>> + */
>> [...]
>>> +
>>> +static const struct samsung_cmu_info peri_cmu_info __initconst = {
>>> +       .gate_clks              = peri_gate_clks,
>>> +       .nr_gate_clks           = ARRAY_SIZE(peri_gate_clks),
>>> +       .clk_regs               = peri_clk_regs,
>>> +       .nr_clk_regs            = ARRAY_SIZE(peri_clk_regs),
>>> +       .nr_clk_ids             = PERI_NR_CLK,
>>> +};
>>> +
>>> +static int __init exynos7870_cmu_probe(struct platform_device *pdev)
>>> +{
>>> +       const struct samsung_cmu_info *info;
>>> +       struct device *dev = &pdev->dev;
>>> +
>>> +       info = of_device_get_match_data(dev);
>>
>> Use device APIs please: device_get_match_data()
> 
> 
> I expect here a follow up patch.
> 
>>
>>> +       exynos_arm64_register_cmu(dev, dev->of_node, info);
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static const struct of_device_id exynos7870_cmu_of_match[] = {
>>> +       {
>>> +               .compatible = "samsung,exynos7870-cmu-mif",
>>> +               .data = &mif_cmu_info,
>>> +       }, {
>>> +               .compatible = "samsung,exynos7870-cmu-dispaud",
>>> +               .data = &dispaud_cmu_info,
>>> +       }, {
>>> +               .compatible = "samsung,exynos7870-cmu-fsys",
>>> +               .data = &fsys_cmu_info,
>>> +       }, {
>>> +               .compatible = "samsung,exynos7870-cmu-g3d",
>>> +               .data = &g3d_cmu_info,
>>> +       }, {
>>> +               .compatible = "samsung,exynos7870-cmu-isp",
>>> +               .data = &isp_cmu_info,
>>> +       }, {
>>> +               .compatible = "samsung,exynos7870-cmu-mfcmscl",
>>> +               .data = &mfcmscl_cmu_info,
>>> +       }, {
>>> +               .compatible = "samsung,exynos7870-cmu-peri",
>>> +               .data = &peri_cmu_info,
>>> +       }, {
>>> +       },
>>> +};
>>> +
>>> +static struct platform_driver exynos7870_cmu_driver __refdata = {
>>
>> Having __refdata here looks wrong.
>>
>>> +       .driver = {
>>> +               .name = "exynos7870-cmu",
>>> +               .of_match_table = exynos7870_cmu_of_match,
>>> +               .suppress_bind_attrs = true,
>>> +       },
>>> +       .probe = exynos7870_cmu_probe,
>>> +};
>>> +
>>> +static int __init exynos7870_cmu_init(void)
>>> +{
>>> +       return platform_driver_register(&exynos7870_cmu_driver);
>>
>> Is this supposed to be platform_driver_probe()? All the __init markings
>> in the samsung clk driver look like potential problems if anything
>> defers or is made into a module.
> 
> Indeed code is confusing but still correct. This is called from
> core_initcall and nothing referencing __init/refdata can defer nor be a
> module. There are modules but, AFAIR, they don't use __init/__refdata.
> 
> The __refdata here was probably so this can reference __initconst in
> other places.
> 
> As you pointed out, probably the correct solution is to use
> platform_driver_probe().
I'll fix this and existing drivers.

Best regards,
Krzysztof