From: Anup Patel <anup.patel@broadcom.com> To: Stephen Boyd <sboyd@codeaurora.org> Cc: Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Michael Turquette <mturquette@baylibre.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Ray Jui <rjui@broadcom.com>, Scott Branden <sbranden@broadcom.com>, Jon Mason <jonmason@broadcom.com>, Florian Fainelli <f.fainelli@gmail.com>, Oza Pawandeep <oza.oza@broadcom.com>, Srinath Mannam <srinath.mannam@broadcom.com>, Pramod Kumar <pramod.kumar@broadcom.com>, Sandeep Tripathy <sandeep.tripathy@broadcom.com>, Device Tree <devicetree@vger.kernel.org>, Linux Kernel <linux-kernel@vger.kernel.org>, linux-clk <linux-clk@vger.kernel.org>, Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>, BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com> Subject: Re: [PATCH v6 03/11] clk: bcm: Add clocks for Stingray SOC Date: Tue, 6 Jun 2017 09:51:20 +0530 [thread overview] Message-ID: <CAALAos8cEc8KN4PE-WUQKNmRzV=GB6YsBJ-4p9mNjs-KduU0Gg@mail.gmail.com> (raw) In-Reply-To: <20170602221052.GT20170@codeaurora.org> On Sat, Jun 3, 2017 at 3:40 AM, Stephen Boyd <sboyd@codeaurora.org> wrote: > On 06/02, Anup Patel wrote: >> diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c >> new file mode 100644 >> index 0000000..342f702 >> --- /dev/null >> +++ b/drivers/clk/bcm/clk-sr.c >> @@ -0,0 +1,320 @@ >> + >> +static const struct iproc_clk_ctrl lcpll_pcie_clk[] = { >> + [BCM_SR_LCPLL_PCIE_PHY_REF_CLK] = { >> + .channel = BCM_SR_LCPLL_PCIE_PHY_REF_CLK, >> + .flags = IPROC_CLK_AON, >> + .enable = ENABLE_VAL(0x0, 7, 1, 13), >> + .mdiv = REG_VAL(0x14, 0, 9), >> + }, >> +}; >> + >> +static void __init sr_lcpll_pcie_clk_init(struct device_node *node) > > Drop __init usage throughout this patch please. Sure, will do. > >> +{ >> + iproc_pll_clk_setup(node, &lcpll_pcie, NULL, 0, lcpll_pcie_clk, >> + ARRAY_SIZE(lcpll_pcie_clk)); >> +} >> + >> +static const struct of_device_id sr_clk_dt_ids[] = { >> +{ .compatible = "brcm,sr-genpll0", .data = sr_genpll0_clk_init, }, >> +{ .compatible = "brcm,sr-genpll4", .data = sr_genpll4_clk_init, }, >> +{ .compatible = "brcm,sr-genpll5", .data = sr_genpll5_clk_init, }, >> +{ .compatible = "brcm,sr-lcpll0", .data = sr_lcpll0_clk_init, }, >> +{ .compatible = "brcm,sr-lcpll1", .data = sr_lcpll1_clk_init, }, >> +{ .compatible = "brcm,sr-lcpll-pcie", .data = sr_lcpll_pcie_clk_init, }, >> +{ /* sentinel */ } > > Please tab these out properly And also leave off the , after the > init function. Sure, will do. > >> +}; >> + >> +static int sr_clk_probe(struct platform_device *pdev) >> +{ >> + const struct of_device_id *device; >> + void (*init_func)(struct device_node *); > > Let's keep this taking the platform device pointer. That way in > the future devm could be used as well as other platform device > APIs without having to change all init signatures. Sounds good, I will make init_func prototype similar to platform driver probe function. > >> + >> + device = of_match_device(sr_clk_dt_ids, &pdev->dev); >> + if (!device) >> + return -ENODEV; >> + init_func = device->data; > > Can use of_device_get_match_data() instead > >> + >> + init_func(pdev->dev.of_node); >> + >> + return 0; >> +} > > It would be pretty nice if we could have some platform driver > common function for this where we want to call different probe > functions for different compatible ids and put them all in the > same driver file. Like platform_driver_of_probe() or something > that then calls a int (*init_func)(struct platform_device *pdev) > directly from the of match table for you. Yes, in-future we can have some API in OF such as: int of_platform_nested_probe(struct platform_device *pdev) This API can be directly set a probe function of some platform driver. It will expect that match data is another platform driver probe function and will call that. IMHO, having nested probe API for OF will certainly help simplify probe functions of quite a few drivers. > >> + >> +static struct platform_driver sr_clk_driver = { > > iproc_sr_* throughout this file? Actually, clk drivers for other iProc SOCs (namely, ns2 and nsp) have only "<soc_name>_" prefix so we are trying to be consistent with these drivers by using "sr_" prefix. Regards, A nup
WARNING: multiple messages have this Message-ID (diff)
From: anup.patel@broadcom.com (Anup Patel) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v6 03/11] clk: bcm: Add clocks for Stingray SOC Date: Tue, 6 Jun 2017 09:51:20 +0530 [thread overview] Message-ID: <CAALAos8cEc8KN4PE-WUQKNmRzV=GB6YsBJ-4p9mNjs-KduU0Gg@mail.gmail.com> (raw) In-Reply-To: <20170602221052.GT20170@codeaurora.org> On Sat, Jun 3, 2017 at 3:40 AM, Stephen Boyd <sboyd@codeaurora.org> wrote: > On 06/02, Anup Patel wrote: >> diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c >> new file mode 100644 >> index 0000000..342f702 >> --- /dev/null >> +++ b/drivers/clk/bcm/clk-sr.c >> @@ -0,0 +1,320 @@ >> + >> +static const struct iproc_clk_ctrl lcpll_pcie_clk[] = { >> + [BCM_SR_LCPLL_PCIE_PHY_REF_CLK] = { >> + .channel = BCM_SR_LCPLL_PCIE_PHY_REF_CLK, >> + .flags = IPROC_CLK_AON, >> + .enable = ENABLE_VAL(0x0, 7, 1, 13), >> + .mdiv = REG_VAL(0x14, 0, 9), >> + }, >> +}; >> + >> +static void __init sr_lcpll_pcie_clk_init(struct device_node *node) > > Drop __init usage throughout this patch please. Sure, will do. > >> +{ >> + iproc_pll_clk_setup(node, &lcpll_pcie, NULL, 0, lcpll_pcie_clk, >> + ARRAY_SIZE(lcpll_pcie_clk)); >> +} >> + >> +static const struct of_device_id sr_clk_dt_ids[] = { >> +{ .compatible = "brcm,sr-genpll0", .data = sr_genpll0_clk_init, }, >> +{ .compatible = "brcm,sr-genpll4", .data = sr_genpll4_clk_init, }, >> +{ .compatible = "brcm,sr-genpll5", .data = sr_genpll5_clk_init, }, >> +{ .compatible = "brcm,sr-lcpll0", .data = sr_lcpll0_clk_init, }, >> +{ .compatible = "brcm,sr-lcpll1", .data = sr_lcpll1_clk_init, }, >> +{ .compatible = "brcm,sr-lcpll-pcie", .data = sr_lcpll_pcie_clk_init, }, >> +{ /* sentinel */ } > > Please tab these out properly And also leave off the , after the > init function. Sure, will do. > >> +}; >> + >> +static int sr_clk_probe(struct platform_device *pdev) >> +{ >> + const struct of_device_id *device; >> + void (*init_func)(struct device_node *); > > Let's keep this taking the platform device pointer. That way in > the future devm could be used as well as other platform device > APIs without having to change all init signatures. Sounds good, I will make init_func prototype similar to platform driver probe function. > >> + >> + device = of_match_device(sr_clk_dt_ids, &pdev->dev); >> + if (!device) >> + return -ENODEV; >> + init_func = device->data; > > Can use of_device_get_match_data() instead > >> + >> + init_func(pdev->dev.of_node); >> + >> + return 0; >> +} > > It would be pretty nice if we could have some platform driver > common function for this where we want to call different probe > functions for different compatible ids and put them all in the > same driver file. Like platform_driver_of_probe() or something > that then calls a int (*init_func)(struct platform_device *pdev) > directly from the of match table for you. Yes, in-future we can have some API in OF such as: int of_platform_nested_probe(struct platform_device *pdev) This API can be directly set a probe function of some platform driver. It will expect that match data is another platform driver probe function and will call that. IMHO, having nested probe API for OF will certainly help simplify probe functions of quite a few drivers. > >> + >> +static struct platform_driver sr_clk_driver = { > > iproc_sr_* throughout this file? Actually, clk drivers for other iProc SOCs (namely, ns2 and nsp) have only "<soc_name>_" prefix so we are trying to be consistent with these drivers by using "sr_" prefix. Regards, A nup
next prev parent reply other threads:[~2017-06-06 4:21 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-02 6:34 [PATCH v6 00/11] Broadcom Stingray SOC Initial Support Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 01/11] dt-bindings: bcm: Add Broadcom Stingray bindings document Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 02/11] dt-bindings: clk: Extend binding doc for Stingray SOC Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 03/11] clk: bcm: Add clocks " Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 22:10 ` Stephen Boyd 2017-06-02 22:10 ` Stephen Boyd 2017-06-06 4:21 ` Anup Patel [this message] 2017-06-06 4:21 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 04/11] arm64: dts: Initial DTS files for Broadcom " Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 05/11] arm64: dts: Add clock DT nodes for " Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 06/11] arm64: dts: Add NAND " Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 07/11] arm64: dts: Add pinctrl " Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 08/11] arm64: dts: Add GPIO " Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 09/11] arm64: dts: Add I2C DT nodes for Stingray SoC Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 10/11] arm64: dts: Add PL022, PL330 and SP805 DT nodes for Stingray Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-02 6:34 ` [PATCH v6 11/11] arm64: dts: Add PWM and SDHCI DT nodes for Stingray SOC Anup Patel 2017-06-02 6:34 ` Anup Patel 2017-06-05 16:51 ` [PATCH v6 00/11] Broadcom Stingray SOC Initial Support Florian Fainelli 2017-06-05 16:51 ` Florian Fainelli 2017-06-06 2:08 ` Florian Fainelli 2017-06-06 2:08 ` Florian Fainelli 2017-06-06 3:20 ` Anup Patel 2017-06-06 3:20 ` Anup Patel 2017-06-06 22:30 ` Stephen Boyd 2017-06-06 22:30 ` Stephen Boyd 2017-06-06 22:30 ` Stephen Boyd 2017-06-20 0:28 ` Florian Fainelli 2017-06-20 0:28 ` Florian Fainelli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAALAos8cEc8KN4PE-WUQKNmRzV=GB6YsBJ-4p9mNjs-KduU0Gg@mail.gmail.com' \ --to=anup.patel@broadcom.com \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=f.fainelli@gmail.com \ --cc=jonmason@broadcom.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mturquette@baylibre.com \ --cc=oza.oza@broadcom.com \ --cc=pramod.kumar@broadcom.com \ --cc=rjui@broadcom.com \ --cc=robh+dt@kernel.org \ --cc=sandeep.tripathy@broadcom.com \ --cc=sboyd@codeaurora.org \ --cc=sbranden@broadcom.com \ --cc=srinath.mannam@broadcom.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.