From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: Timo Alho <talho-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, Peter De Schrijver <pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, Sivaram Nair <sivaramn-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, Joseph Lo <josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH v3 11/12] clk: tegra: Add BPMP clock driver Date: Mon, 22 Aug 2016 13:47:13 -0600 [thread overview] Message-ID: <30386cdd-ea1d-25bc-cbe2-831c94209a99@wwwdotorg.org> (raw) In-Reply-To: <20160819173233.13260-12-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> On 08/19/2016 11:32 AM, Thierry Reding wrote: > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> > > This driver uses the services provided by the BPMP firmware driver to > implement a clock driver based on the MRQ_CLK request. This part of the > BPMP ABI provides a means to enumerate and control clocks and should > allow the driver to work on any chip that supports this ABI. > diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c > +#define TEGRA_BPMP_CLK_HAS_MUX BIT(0) > +#define TEGRA_BPMP_CLK_HAS_SET_RATE BIT(1) > +#define TEGRA_BPMP_CLK_IS_ROOT BIT(2) Shouldn't those be defined in the BPMP ABI header? > +static int > +tegra_bpmp_clk_transfer_atomic(struct tegra_bpmp *bpmp, > + const struct tegra_bpmp_clk_message *clk) > +{ > + struct mrq_clk_request request; > + struct tegra_bpmp_message msg; > + void *req = (void *)&request; > + > + memset(&request, 0, sizeof(request)); > + request.cmd_and_id = (clk->cmd << 24) | clk->clk; > + memcpy(req + 4, clk->tx.data, clk->tx.size); So the TX payload gets memcpy()d once here to combine it with the request header, and again inside the BPMP driver to copy it to the IVC shared memory. Does it make sense to eliminate the copy here, and require callers to allocate and fill in the entire TX structure? The "(clk->cmd << 24) | clk->clk" could be wrapped in a static inline function to avoid any duplication of logic. > +static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp, > + const struct tegra_bpmp_clk_message *clk) ... > + err = tegra_bpmp_transfer(bpmp, &msg); > + if (err != -EAGAIN) > + return err; > + > + return __tegra_bpmp_clk_transfer_atomic(bpmp, &msg); > +} This seems odd; can you add some comments indicating why there's a need for a retry, and why it falls back to the _atomic() function rather than just retrying? Nit: Perhaps s/tegra_bpmp_clk/tegra_clk_bpmp/ for all symbols implemented in this driver; it can be a little hard to tell which function calls are to the Tegra BPMP driver (tegra_bpmp_*), and which are to the Tegra clock driver that's implemented using BPMP (tegra_bpmp_clk_*). > +static int tegra_bpmp_clk_set_rate(struct clk_hw *hw, unsigned long rate, > + unsigned long parent_rate) > +{ > + return 0; > +} > + > +static long tegra_bpmp_clk_round_rate(struct clk_hw *hw, unsigned long rate, > + unsigned long *parent_rate) > +{ > + return 0; > +} > + > +static unsigned long tegra_bpmp_clk_recalc_rate(struct clk_hw *hw, > + unsigned long parent_rate) > +{ > + return 0; > +} Aren't those all missing an implementation? > +static int tegra_bpmp_probe_clocks(struct tegra_bpmp *bpmp, > + struct tegra_bpmp_clk_info **clocksp) > + for (id = 0; id <= max_id; id++) { > + struct tegra_bpmp_clk_info *info = &clocks[count]; > +#if 0 > + const char *prefix = ""; > + struct seq_buf buf; > + unsigned int i; > + char flags[64]; > +#endif Should the #if 0 be removed? checkpatch would warn about this; was it run and if not would it find other things to complain about? > +static struct clk_hw * > +tegra_bpmp_clk_register(struct tegra_bpmp *bpmp, > + const struct tegra_bpmp_clk_info *info, > + const struct tegra_bpmp_clk_info *clocks, > + unsigned int num_clocks) > +{ > + struct tegra_bpmp_clk *priv; > + struct clk_init_data init; ... > + /* hardware clock initialization */ > + priv->hw.init = &init; > + init.name = info->name; ... > + clk = clk_register(bpmp->dev, &priv->hw); Is priv->hw.init guaranteed to only be used inside the call to clk_register()? If not, it's storing a pointer to the stack for longer than it's valid. > + parents = kcalloc(info->num_parents, sizeof(*parents), GFP_KERNEL); > + if (!parents) > + return ERR_PTR(-ENOMEM); That needs to free priv->parents which was allocated earlier this function. > +static struct clk_hw *tegra_bpmp_clk_of_xlate(struct of_phandle_args *clkspec, > + void *data) > +{ > + unsigned int id = clkspec->args[0], i; Should this function validate the cell count first? Too small means args[0] doesn't contain valid data, and too large means the DT is bogus, and we should at least warn the user they've included extra cruft, since it could in theory gain additional meaning later on if the binding gets extended.
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3 11/12] clk: tegra: Add BPMP clock driver Date: Mon, 22 Aug 2016 13:47:13 -0600 [thread overview] Message-ID: <30386cdd-ea1d-25bc-cbe2-831c94209a99@wwwdotorg.org> (raw) In-Reply-To: <20160819173233.13260-12-thierry.reding@gmail.com> On 08/19/2016 11:32 AM, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > This driver uses the services provided by the BPMP firmware driver to > implement a clock driver based on the MRQ_CLK request. This part of the > BPMP ABI provides a means to enumerate and control clocks and should > allow the driver to work on any chip that supports this ABI. > diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c > +#define TEGRA_BPMP_CLK_HAS_MUX BIT(0) > +#define TEGRA_BPMP_CLK_HAS_SET_RATE BIT(1) > +#define TEGRA_BPMP_CLK_IS_ROOT BIT(2) Shouldn't those be defined in the BPMP ABI header? > +static int > +tegra_bpmp_clk_transfer_atomic(struct tegra_bpmp *bpmp, > + const struct tegra_bpmp_clk_message *clk) > +{ > + struct mrq_clk_request request; > + struct tegra_bpmp_message msg; > + void *req = (void *)&request; > + > + memset(&request, 0, sizeof(request)); > + request.cmd_and_id = (clk->cmd << 24) | clk->clk; > + memcpy(req + 4, clk->tx.data, clk->tx.size); So the TX payload gets memcpy()d once here to combine it with the request header, and again inside the BPMP driver to copy it to the IVC shared memory. Does it make sense to eliminate the copy here, and require callers to allocate and fill in the entire TX structure? The "(clk->cmd << 24) | clk->clk" could be wrapped in a static inline function to avoid any duplication of logic. > +static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp, > + const struct tegra_bpmp_clk_message *clk) ... > + err = tegra_bpmp_transfer(bpmp, &msg); > + if (err != -EAGAIN) > + return err; > + > + return __tegra_bpmp_clk_transfer_atomic(bpmp, &msg); > +} This seems odd; can you add some comments indicating why there's a need for a retry, and why it falls back to the _atomic() function rather than just retrying? Nit: Perhaps s/tegra_bpmp_clk/tegra_clk_bpmp/ for all symbols implemented in this driver; it can be a little hard to tell which function calls are to the Tegra BPMP driver (tegra_bpmp_*), and which are to the Tegra clock driver that's implemented using BPMP (tegra_bpmp_clk_*). > +static int tegra_bpmp_clk_set_rate(struct clk_hw *hw, unsigned long rate, > + unsigned long parent_rate) > +{ > + return 0; > +} > + > +static long tegra_bpmp_clk_round_rate(struct clk_hw *hw, unsigned long rate, > + unsigned long *parent_rate) > +{ > + return 0; > +} > + > +static unsigned long tegra_bpmp_clk_recalc_rate(struct clk_hw *hw, > + unsigned long parent_rate) > +{ > + return 0; > +} Aren't those all missing an implementation? > +static int tegra_bpmp_probe_clocks(struct tegra_bpmp *bpmp, > + struct tegra_bpmp_clk_info **clocksp) > + for (id = 0; id <= max_id; id++) { > + struct tegra_bpmp_clk_info *info = &clocks[count]; > +#if 0 > + const char *prefix = ""; > + struct seq_buf buf; > + unsigned int i; > + char flags[64]; > +#endif Should the #if 0 be removed? checkpatch would warn about this; was it run and if not would it find other things to complain about? > +static struct clk_hw * > +tegra_bpmp_clk_register(struct tegra_bpmp *bpmp, > + const struct tegra_bpmp_clk_info *info, > + const struct tegra_bpmp_clk_info *clocks, > + unsigned int num_clocks) > +{ > + struct tegra_bpmp_clk *priv; > + struct clk_init_data init; ... > + /* hardware clock initialization */ > + priv->hw.init = &init; > + init.name = info->name; ... > + clk = clk_register(bpmp->dev, &priv->hw); Is priv->hw.init guaranteed to only be used inside the call to clk_register()? If not, it's storing a pointer to the stack for longer than it's valid. > + parents = kcalloc(info->num_parents, sizeof(*parents), GFP_KERNEL); > + if (!parents) > + return ERR_PTR(-ENOMEM); That needs to free priv->parents which was allocated earlier this function. > +static struct clk_hw *tegra_bpmp_clk_of_xlate(struct of_phandle_args *clkspec, > + void *data) > +{ > + unsigned int id = clkspec->args[0], i; Should this function validate the cell count first? Too small means args[0] doesn't contain valid data, and too large means the DT is bogus, and we should at least warn the user they've included extra cruft, since it could in theory gain additional meaning later on if the binding gets extended.
next prev parent reply other threads:[~2016-08-22 19:47 UTC|newest] Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-19 17:32 [PATCH v3 00/12] Initial Tegra186 support Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-19 17:32 ` [PATCH v3 01/12] dt-bindings: mailbox: Add Tegra HSP binding Thierry Reding 2016-08-19 17:32 ` Thierry Reding 2016-08-19 17:32 ` [PATCH v3 02/12] mailbox: Add Tegra HSP driver Thierry Reding 2016-08-19 17:32 ` Thierry Reding 2016-08-22 13:43 ` Arnd Bergmann 2016-08-22 13:43 ` Arnd Bergmann 2016-08-22 14:17 ` Thierry Reding 2016-08-22 14:17 ` Thierry Reding [not found] ` <20160822141728.GF17367-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org> 2016-08-22 16:42 ` Stephen Warren 2016-08-22 16:42 ` Stephen Warren [not found] ` <20160819173233.13260-3-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 16:53 ` Stephen Warren 2016-08-22 16:53 ` Stephen Warren 2016-08-23 0:06 ` Sivaram Nair 2016-08-23 0:06 ` Sivaram Nair 2016-08-23 0:12 ` Sivaram Nair 2016-08-23 0:12 ` Sivaram Nair 2016-08-19 17:32 ` [PATCH v3 03/12] dt-bindings: firmware: Add bindings for Tegra BPMP Thierry Reding 2016-08-19 17:32 ` Thierry Reding 2016-08-19 17:32 ` [PATCH v3 04/12] firmware: tegra: Add IVC library Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-5-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 10:46 ` Jon Hunter 2016-08-22 10:46 ` Jon Hunter [not found] ` <90222c3a-7c69-6fa3-d161-4ed0c5759f34-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-08-22 12:40 ` Thierry Reding 2016-08-22 12:40 ` Thierry Reding 2016-08-22 18:49 ` Stephen Warren 2016-08-22 18:49 ` Stephen Warren 2016-08-24 15:13 ` Jon Hunter 2016-08-24 15:13 ` Jon Hunter 2016-08-19 17:32 ` [PATCH v3 05/12] firmware: tegra: Add BPMP support Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-6-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 9:26 ` Jon Hunter 2016-08-22 9:26 ` Jon Hunter [not found] ` <94227d94-1d60-fda7-731b-26656633d585-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-08-22 12:54 ` Thierry Reding 2016-08-22 12:54 ` Thierry Reding [not found] ` <20160822125458.GC17367-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org> 2016-08-22 14:24 ` Jon Hunter 2016-08-22 14:24 ` Jon Hunter [not found] ` <6bb4d32f-4f13-285e-430e-672f375a9a46-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-08-22 15:00 ` Thierry Reding 2016-08-22 15:00 ` Thierry Reding 2016-08-22 18:51 ` Stephen Warren 2016-08-22 18:51 ` Stephen Warren 2016-08-22 13:34 ` Arnd Bergmann 2016-08-22 13:34 ` Arnd Bergmann 2016-08-22 14:02 ` Thierry Reding 2016-08-22 14:02 ` Thierry Reding [not found] ` <20160822140211.GE17367-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org> 2016-08-22 14:42 ` Arnd Bergmann 2016-08-22 14:42 ` Arnd Bergmann 2016-08-22 15:32 ` Thierry Reding 2016-08-22 15:32 ` Thierry Reding [not found] ` <20160822153258.GB21012-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org> 2016-08-22 15:43 ` Arnd Bergmann 2016-08-22 15:43 ` Arnd Bergmann 2016-08-22 18:56 ` Stephen Warren 2016-08-22 18:56 ` Stephen Warren 2016-08-23 14:58 ` Arnd Bergmann 2016-08-23 14:58 ` Arnd Bergmann 2016-08-23 23:26 ` Sivaram Nair 2016-08-23 23:26 ` Sivaram Nair 2016-08-22 22:23 ` Stephen Warren 2016-08-22 22:23 ` Stephen Warren 2016-08-19 17:32 ` [PATCH v3 06/12] soc/tegra: Add Tegra186 support Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-7-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 19:01 ` Stephen Warren 2016-08-22 19:01 ` Stephen Warren 2016-08-23 13:44 ` Jon Hunter 2016-08-23 13:44 ` Jon Hunter 2016-08-19 17:32 ` [PATCH v3 07/12] arm64: defconfig: Enable Tegra186 SoC Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-8-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 19:01 ` Stephen Warren 2016-08-22 19:01 ` Stephen Warren 2016-08-19 17:32 ` [PATCH v3 08/12] arm64: dts: tegra: Add Tegra186 support Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-9-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 17:11 ` Stephen Warren 2016-08-22 17:11 ` Stephen Warren 2016-08-22 19:07 ` Stephen Warren 2016-08-22 19:07 ` Stephen Warren 2016-08-19 17:32 ` [PATCH v3 09/12] arm64: dts: tegra: Add NVIDIA P3310 main board support Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-10-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 19:08 ` Stephen Warren 2016-08-22 19:08 ` Stephen Warren 2016-08-23 17:35 ` Jon Hunter 2016-08-23 17:35 ` Jon Hunter 2016-08-19 17:32 ` [PATCH v3 10/12] arm64: dts: tegra: Add NVIDIA P2771 " Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-11-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 19:11 ` Stephen Warren 2016-08-22 19:11 ` Stephen Warren 2016-08-19 17:32 ` [PATCH v3 11/12] clk: tegra: Add BPMP clock driver Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-12-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 10:11 ` Jon Hunter 2016-08-22 10:11 ` Jon Hunter [not found] ` <0d7080bc-9e82-75dd-7169-0a5b7429801e-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-08-22 13:28 ` Thierry Reding 2016-08-22 13:28 ` Thierry Reding [not found] ` <20160822132833.GD17367-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org> 2016-08-23 13:49 ` Jon Hunter 2016-08-23 13:49 ` Jon Hunter 2016-08-22 19:47 ` Stephen Warren [this message] 2016-08-22 19:47 ` Stephen Warren 2016-08-19 17:32 ` [PATCH v3 12/12] reset: Add Tegra BPMP reset driver Thierry Reding 2016-08-19 17:32 ` Thierry Reding [not found] ` <20160819173233.13260-13-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-08-22 19:56 ` Stephen Warren 2016-08-22 19:56 ` Stephen Warren 2016-11-26 13:39 ` [PATCH v3 00/12] Initial Tegra186 support Pavel Machek 2016-11-26 13:39 ` Pavel Machek [not found] ` <20161126133927.GE20568-5NIqAleC692hcjWhqY66xCZi+YwRKgec@public.gmane.org> 2016-11-28 7:33 ` Thierry Reding 2016-11-28 7:33 ` Thierry Reding
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=30386cdd-ea1d-25bc-cbe2-831c94209a99@wwwdotorg.org \ --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=sivaramn-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=talho-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ /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.