From: Stephen Boyd <sboyd@codeaurora.org> To: Tero Kristo <t-kristo@ti.com> Cc: linux-clk@vger.kernel.org, mturquette@baylibre.com, ssantosh@kernel.org, nm@ti.com, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org Subject: Re: [PATCH 3/3] clk: keystone: Add sci-clk driver support Date: Mon, 12 Dec 2016 11:38:02 -0800 [thread overview] Message-ID: <20161212193800.GL5423@codeaurora.org> (raw) In-Reply-To: <22dacb0c-a3bc-50ce-e4b9-f74a0c706f20@ti.com> On 12/09, Tero Kristo wrote: > On 08/12/16 23:10, Stephen Boyd wrote: > >On 12/08, Tero Kristo wrote: > >>On 08/12/16 02:13, Stephen Boyd wrote: > >>>On 10/21, Tero Kristo wrote: > >>>>diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c > >>>>new file mode 100644 > >>>>index 0000000..f6af5bd > >>>>--- /dev/null > >>>>+++ b/drivers/clk/keystone/sci-clk.c > >> > >>> > >>>>+ > >>>>+ handle = devm_ti_sci_get_handle(dev); > >>>>+ if (IS_ERR(handle)) > >>>>+ return PTR_ERR(handle); > >>>>+ > >>>>+ provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL); > >>>>+ if (!provider) > >>>>+ return -ENOMEM; > >>>>+ > >>>>+ provider->clocks = data; > >>>>+ > >>>>+ provider->sci = handle; > >>>>+ provider->ops = &handle->ops.clk_ops; > >>>>+ provider->dev = dev; > >>>>+ > >>>>+ ti_sci_init_clocks(provider); > >>> > >>>And if this fails? > >> > >>Yea this is kind of controversial. ti_sci_init_clocks() can fail if > >>any of the clocks registered will fail. I decided to have it this > >>way so that at least some clocks might work in failure cause, and > >>you might have a booting device instead of total lock-up. > >> > >>Obviously it could be done so that if any clock fails, we would > >>de-register all clocks at that point, but personally I think this is > >>a worse option. > >> > >>ti_sci_init_clocks could probably be modified to continue > >>registering clocks when a single clock fails though. Currently it > >>aborts at first failure. > >> > > > >That sounds like a better approach if we don't care about > >failures to register a clock. Returning a value from a function > >and not using it isn't really a great design. > > > >I worry that if we start returning errors from clk_hw_register() > >that something will go wrong though, so really I don't know why > >we want to ignore errors at all. Just for debugging a boot hang? > >Can't we use early console to at least see that this driver is > >failing to probe and debug that way? > > Early console can be used to debug that, but it is kind of annoying > to recompile most of the kernel when you suddenly need to use it. I thought SERIAL_EARLYCON was selected by drivers that support it? So there shouldn't be any rebuilding required. > > How about modifying the ti_sci_init_clocks func to print an error > for each failed clock? Ok that's fine too. I'd prefer the function had a return type of void if we're not planning on using the return value, that's all. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 3/3] clk: keystone: Add sci-clk driver support Date: Mon, 12 Dec 2016 11:38:02 -0800 [thread overview] Message-ID: <20161212193800.GL5423@codeaurora.org> (raw) In-Reply-To: <22dacb0c-a3bc-50ce-e4b9-f74a0c706f20@ti.com> On 12/09, Tero Kristo wrote: > On 08/12/16 23:10, Stephen Boyd wrote: > >On 12/08, Tero Kristo wrote: > >>On 08/12/16 02:13, Stephen Boyd wrote: > >>>On 10/21, Tero Kristo wrote: > >>>>diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c > >>>>new file mode 100644 > >>>>index 0000000..f6af5bd > >>>>--- /dev/null > >>>>+++ b/drivers/clk/keystone/sci-clk.c > >> > >>> > >>>>+ > >>>>+ handle = devm_ti_sci_get_handle(dev); > >>>>+ if (IS_ERR(handle)) > >>>>+ return PTR_ERR(handle); > >>>>+ > >>>>+ provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL); > >>>>+ if (!provider) > >>>>+ return -ENOMEM; > >>>>+ > >>>>+ provider->clocks = data; > >>>>+ > >>>>+ provider->sci = handle; > >>>>+ provider->ops = &handle->ops.clk_ops; > >>>>+ provider->dev = dev; > >>>>+ > >>>>+ ti_sci_init_clocks(provider); > >>> > >>>And if this fails? > >> > >>Yea this is kind of controversial. ti_sci_init_clocks() can fail if > >>any of the clocks registered will fail. I decided to have it this > >>way so that at least some clocks might work in failure cause, and > >>you might have a booting device instead of total lock-up. > >> > >>Obviously it could be done so that if any clock fails, we would > >>de-register all clocks at that point, but personally I think this is > >>a worse option. > >> > >>ti_sci_init_clocks could probably be modified to continue > >>registering clocks when a single clock fails though. Currently it > >>aborts at first failure. > >> > > > >That sounds like a better approach if we don't care about > >failures to register a clock. Returning a value from a function > >and not using it isn't really a great design. > > > >I worry that if we start returning errors from clk_hw_register() > >that something will go wrong though, so really I don't know why > >we want to ignore errors at all. Just for debugging a boot hang? > >Can't we use early console to at least see that this driver is > >failing to probe and debug that way? > > Early console can be used to debug that, but it is kind of annoying > to recompile most of the kernel when you suddenly need to use it. I thought SERIAL_EARLYCON was selected by drivers that support it? So there shouldn't be any rebuilding required. > > How about modifying the ti_sci_init_clocks func to print an error > for each failed clock? Ok that's fine too. I'd prefer the function had a return type of void if we're not planning on using the return value, that's all. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2016-12-12 19:38 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-10-21 12:45 [PATCH 0/3] clk: keystone: add sci clock support Tero Kristo 2016-10-21 12:45 ` Tero Kristo 2016-10-21 12:45 ` Tero Kristo 2016-10-21 12:45 ` [PATCH 1/3] Documentation: dt: Add TI SCI clock driver Tero Kristo 2016-10-21 12:45 ` Tero Kristo 2016-10-21 12:45 ` Tero Kristo 2016-10-30 20:41 ` Rob Herring 2016-10-30 20:41 ` Rob Herring 2016-10-31 12:50 ` Tero Kristo 2016-10-31 12:50 ` Tero Kristo 2016-10-31 12:50 ` Tero Kristo 2016-10-31 20:34 ` Nishanth Menon 2016-10-31 20:34 ` Nishanth Menon 2016-10-31 20:34 ` Nishanth Menon 2016-11-18 17:20 ` Rob Herring 2016-11-18 17:20 ` Rob Herring [not found] ` <CAL_JsqLtSs6ifnMdEOsfXpGoWnmXuGAx83+ziB9yU+zurvob+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-11-21 8:14 ` Tero Kristo 2016-11-21 8:14 ` Tero Kristo 2016-11-21 8:14 ` Tero Kristo 2016-12-02 8:19 ` Tero Kristo 2016-12-02 8:19 ` Tero Kristo 2016-12-02 18:45 ` Rob Herring 2016-12-02 18:45 ` Rob Herring 2016-12-02 18:58 ` Stephen Boyd 2016-12-02 18:58 ` Stephen Boyd [not found] ` <5f146fb6-ec88-b7ee-ef5b-a5ad32c54a74-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2016-12-02 21:07 ` Tero Kristo 2016-12-02 21:07 ` Tero Kristo 2016-12-02 21:07 ` Tero Kristo 2016-10-21 12:46 ` [PATCH 2/3] dt-binding: clock: Add k2g clock definitions Tero Kristo 2016-10-21 12:46 ` Tero Kristo 2016-10-21 12:46 ` Tero Kristo 2017-05-16 15:03 ` Tero Kristo 2017-05-16 15:03 ` Tero Kristo 2016-10-21 12:46 ` [PATCH 3/3] clk: keystone: Add sci-clk driver support Tero Kristo 2016-10-21 12:46 ` Tero Kristo 2016-10-21 12:46 ` Tero Kristo 2016-12-08 0:13 ` Stephen Boyd 2016-12-08 0:13 ` Stephen Boyd 2016-12-08 10:45 ` Tero Kristo 2016-12-08 10:45 ` Tero Kristo 2016-12-08 10:45 ` Tero Kristo 2016-12-08 21:10 ` Stephen Boyd 2016-12-08 21:10 ` Stephen Boyd [not found] ` <20161208211044.GI5423-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2016-12-09 8:05 ` Tero Kristo 2016-12-09 8:05 ` Tero Kristo 2016-12-09 8:05 ` Tero Kristo 2016-12-12 19:38 ` Stephen Boyd [this message] 2016-12-12 19:38 ` Stephen Boyd [not found] ` <20161212193800.GL5423-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2016-12-13 9:01 ` Tero Kristo 2016-12-13 9:01 ` Tero Kristo 2016-12-13 9:01 ` Tero Kristo -- strict thread matches above, loose matches on Subject: below -- 2016-08-20 0:33 [PATCH 0/3] ARM: K2G: Add support for TI-SCI Clocks Nishanth Menon 2016-08-20 0:33 ` [PATCH 3/3] clk: keystone: Add sci-clk driver support Nishanth Menon 2016-08-20 0:33 ` Nishanth Menon 2016-08-20 0:33 ` Nishanth Menon 2016-08-24 8:34 ` Stephen Boyd 2016-08-24 8:34 ` Stephen Boyd 2016-08-24 8:34 ` Stephen Boyd 2016-08-31 18:35 ` Tero Kristo 2016-08-31 18:35 ` Tero Kristo 2016-08-31 18:35 ` Tero Kristo 2016-08-31 22:31 ` Stephen Boyd 2016-08-31 22:31 ` Stephen Boyd 2016-08-31 22:31 ` Stephen Boyd 2016-09-01 12:27 ` Tero Kristo 2016-09-01 12:27 ` Tero Kristo 2016-09-01 12:27 ` Tero Kristo
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=20161212193800.GL5423@codeaurora.org \ --to=sboyd@codeaurora.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=mturquette@baylibre.com \ --cc=nm@ti.com \ --cc=ssantosh@kernel.org \ --cc=t-kristo@ti.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.