[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1530327.jvk44KuFQA@flatron>
Date: Sat, 21 Sep 2013 14:50:51 +0200
From: Tomasz Figa <tomasz.figa@...il.com>
To: Andrew Bresticker <abrestic@...omium.org>
Cc: linux-samsung-soc@...r.kernel.org,
Rob Herring <rob.herring@...xeda.com>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Stephen Warren <swarren@...dotorg.org>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Rob Landley <rob@...dley.net>,
Kukjin Kim <kgene.kim@...sung.com>,
Russell King <linux@....linux.org.uk>,
Mike Turquette <mturquette@...aro.org>,
Grant Likely <grant.likely@...aro.org>,
Sachin Kamat <sachin.kamat@...aro.org>,
Jiri Kosina <jkosina@...e.cz>,
Rahul Sharma <rahul.sharma@...sung.com>,
Leela Krishna Amudala <l.krishna@...sung.com>,
Stephen Boyd <sboyd@...eaurora.org>,
Tomasz Figa <t.figa@...sung.com>,
Tushar Behera <tushar.behera@...aro.org>,
Yadwinder Singh Brar <yadi.brar@...sung.com>,
Doug Anderson <dianders@...omium.org>,
Padmavathi Venna <padma.v@...sung.com>,
devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] clk: exynos-audss: convert to platform device
Hi Andrew,
This patch looks good overall, but I have some minor comments inline.
On Friday 20 of September 2013 14:13:52 Andrew Bresticker wrote:
> The Exynos AudioSS clock controller will later be modified to allow
> input clocks to be specified via device-tree in order to support
> multiple Exynos SoCs. This will introduce a dependency on the core
> SoC clock controller being initialized first so that the AudioSS driver
> can look up its input clocks, but the order in which clock providers
> are probed in of_clk_init() is not guaranteed. Since deferred probing
> is not supported in of_clk_init() and the AudioSS block is not the core
> controller, we can initialize it later as a platform device.
>
> Signed-off-by: Andrew Bresticker <abrestic@...omium.org>
> ---
> drivers/clk/samsung/clk-exynos-audss.c | 71
> +++++++++++++++++++++++++++------- 1 file changed, 58 insertions(+), 13
> deletions(-)
[snip]
> +static int exynos_audss_clk_remove(struct platform_device *pdev)
> +{
> + of_clk_del_provider(pdev->dev.of_node);
> +
> + return 0;
> }
Don't we need to unregister all the registered clocks in remove? This also
leads to another question: Do we even need removal support for this
driver?
> -CLK_OF_DECLARE(exynos4210_audss_clk, "samsung,exynos4210-audss-clock",
> - exynos_audss_clk_init);
> -CLK_OF_DECLARE(exynos5250_audss_clk, "samsung,exynos5250-audss-clock",
> - exynos_audss_clk_init);
> +
> +static const struct of_device_id exynos_audss_clk_of_match[] = {
> + { .compatible = "samsung,exynos4210-audss-clock", },
> + { .compatible = "samsung,exynos5250-audss-clock", },
> + {},
> +};
> +
> +static struct platform_driver exynos_audss_clk_driver = {
> + .driver = {
> + .name = "exynos-audss-clk",
> + .owner = THIS_MODULE,
> + .of_match_table = exynos_audss_clk_of_match,
> + },
> + .probe = exynos_audss_clk_probe,
> + .remove = exynos_audss_clk_remove,
> +};
> +
> +static int __init exynos_audss_clk_init(void)
> +{
> + return platform_driver_register(&exynos_audss_clk_driver);
> +}
> +core_initcall(exynos_audss_clk_init);
Does it need to be core_initcall? Drivers depending on clocks provided by
this driver should be able to defer probing if they are probed before this
driver.
Then you would be able to simply use module_platform_driver() below.
> +static void __init exynos_audss_clk_exit(void)
> +{
> + platform_driver_unregister(&exynos_audss_clk_driver);
> +}
> +module_exit(exynos_audss_clk_exit);
> +
> +MODULE_AUTHOR("Padmavathi Venna <padma.v@...sung.com>");
> +MODULE_DESCRIPTION("Exynos AudioSS Clock Controller");
nit: IMHO Audio Subsystem instead of AudioSS would be more meaningful.
> +MODULE_LICENSE("GPL");
This should be GPL v2.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists