| Message ID | 20191230193127.8803-1-samuel@sholland.org (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
| Series | [RFC] clk: Implement protected-clocks for all OF clock providers | expand |
Hi, (Thanks for that good commit log) On Mon, Dec 30, 2019 at 01:31:27PM -0600, Samuel Holland wrote: > This is a generic implementation of the "protected-clocks" property from > the common clock binding. It comes with some caveats: > > 1) Clocks that have CLK_IS_CRITICAL in their init data are prepared/ > enabled before they are attached to the clock tree. protected-clocks are > only protected once the clock provider is added, which is generally > after all of the clocks it provides have been registered. This leaves a > window of opportunity where something could disable or modify the clock, > such as a driver running on another CPU, or the clock core itself. There > is a comment to this effect in __clk_core_init(): > > /* > * Enable CLK_IS_CRITICAL clocks so newly added critical clocks > * don't get accidentally disabled when walking the orphan tree and > * reparenting clocks > */ > > Similarly, these clocks will be enabled after they are first reparented, > unlike other CLK_IS_CRITICAL clocks. See the comment in > clk_core_reparent_orphans_nolock(): > > /* > * We need to use __clk_set_parent_before() and _after() to > * to properly migrate any prepare/enable count of the orphan > * clock. This is important for CLK_IS_CRITICAL clocks, which > * are enabled during init but might not have a parent yet. > */ > > Ideally we could detect protected clocks before they are reparented, but > there are two problems with that: > > i) From the clock core's perspective, hw->init is const. > > ii) The clock core doesn't see the device_node until __clk_register is > called on the first clock. > > So the only race-free way to detect protected-clocks is to do it in the > middle of __clk_register, between when core->flags is initialized and > calling __clk_core_init(). That requires scanning the device tree again > for each clock, which is part of why I didn't do it that way. > > 2) __clk_protect needs to be idempotent, for two reasons: > > i) Clocks with CLK_IS_CRITICAL in their init data are already > prepared/enabled, and we don't want to prepare/enable them again. > Note that if the clock did not have CLK_SET_RATE_GATE in its init > data, it was *not* rate protected during the initial call to > clk_core_prepare(). As far as I can tell, none of the other flags > affect the internal state of the clock, so they don't need any > "parallel reconstruction". > > ii) of_clk_set_defaults() is called twice for (at least some) clock > controllers registered with CLK_OF_DECLARE. It is called first in > of_clk_add_provider()/of_clk_add_hw_provider() inside clk_init_cb, > and again afterward in of_clk_init(). I think that the second call > in of_clk_init() should be removed, but that would require > auditing all users of CLK_OF_DECLARE to ensure they called one of > the of_clk_add{,_hw}_provider functions. > > 3) It is not clear specifically which flags should be implied by being > in protected-clocks. I took it to mean "this clock is outside of OS > control, so don't modify it, and assume it can change at any time". > > For that reason, I added the following flags: > - CLK_SET_RATE_GATE: prevents clk_set_rate() once prepared > - CLK_SET_PARENT_GATE: prevents clk_set_parent() once prepared I'm not sure the reasoning about the fact that the clock is outside of OS control and therefore cannot change rate is correct. Using crust as an example, if you were to all the PRCM clocks handling code in it, you would have already a number of cases where we would need to change the rate. I2C bus rate and IR comes to my mind. CPUFreq is another common example of a setup where the clock itself is outside of the OS control, but still the OS initiates the rate change. The RPi also has a PLL to control the whole display block that needs to be configured depending on the resolution being displayed (and other things), and is handled by the videocore firmware. Of course, once the OS has asked for that new rate, the firmware is entirely free to ignore it as long as it's properly reported to the clock framework. But completely disabling the rates changes seems a bit overkill. > - CLK_GET_RATE_NOCACHE: allows the rate to change behind the OS's back > - CLK_GET_ACCURACY_NOCACHE: ditto for the accuracy So I was part of the discussions of the protected-clocks stuff a few years ago and IIRC the discussions were only about the OS not disabling the clocks. I guess the arguments are sound though, but at the same time it's pretty easy (and cheap) to do it at the driver level, and that would make sense too. So I don't really know what to think here :) Thanks for starting that discussion! Maxime
diff --git a/drivers/clk/clk-conf.c b/drivers/clk/clk-conf.c index 2ef819606c41..a57d28b0f397 100644 --- a/drivers/clk/clk-conf.c +++ b/drivers/clk/clk-conf.c @@ -11,6 +11,54 @@ #include <linux/of.h> #include <linux/printk.h> +#include "clk.h" + +static int __set_clk_flags(struct device_node *node) +{ + struct of_phandle_args clkspec; + struct property *prop; + int i, index = 0, rc; + const __be32 *cur; + struct clk *clk; + u32 nr_cells; + + rc = of_property_read_u32(node, "#clock-cells", &nr_cells); + if (rc < 0) { + pr_err("clk: missing #clock-cells property on %pOF\n", node); + return rc; + } + + clkspec.np = node; + clkspec.args_count = nr_cells; + + of_property_for_each_u32(node, "protected-clocks", prop, cur, clkspec.args[0]) { + /* read the remainder of the clock specifier */ + for (i = 1; i < nr_cells; ++i) { + cur = of_prop_next_u32(prop, cur, &clkspec.args[i]); + if (!cur) { + pr_err("clk: invalid value of protected-clocks" + " property at %pOF\n", node); + return -EINVAL; + } + } + clk = of_clk_get_from_provider(&clkspec); + if (IS_ERR(clk)) { + if (PTR_ERR(clk) != -EPROBE_DEFER) + pr_err("clk: couldn't get protected clock" + " %u for %pOF\n", index, node); + return PTR_ERR(clk); + } + + rc = __clk_protect(clk); + if (rc < 0) + pr_warn("clk: failed to protect %s: %d\n", + __clk_get_name(clk), rc); + clk_put(clk); + index++; + } + return 0; +} + static int __set_clk_parents(struct device_node *node, bool clk_supplier) { struct of_phandle_args clkspec; @@ -135,6 +183,12 @@ int of_clk_set_defaults(struct device_node *node, bool clk_supplier) if (!node) return 0; + if (clk_supplier) { + rc = __set_clk_flags(node); + if (rc < 0) + return rc; + } + rc = __set_clk_parents(node, clk_supplier); if (rc < 0) return rc; diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 6a11239ccde3..e115e0199535 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -4038,6 +4038,50 @@ void devm_clk_hw_unregister(struct device *dev, struct clk_hw *hw) } EXPORT_SYMBOL_GPL(devm_clk_hw_unregister); +/* + * clk-conf helpers + */ + +int __clk_protect(struct clk *clk) +{ + struct clk_core *core = clk->core; + long prev_flags; + int ret = 0; + + clk_prepare_lock(); + + prev_flags = core->flags; + core->flags |= CLK_SET_RATE_GATE | + CLK_SET_PARENT_GATE | + CLK_GET_RATE_NOCACHE | + CLK_GET_ACCURACY_NOCACHE | + CLK_IS_CRITICAL; + + /* + * If CLK_IS_CRITICAL was set in the clock's init data, then + * the clock was already prepared/enabled when it was added. + * + * However, if CLK_SET_RATE_GATE was not set, rate protection was + * not applied during clk_core_prepare(), and should be added now. + */ + if (prev_flags & CLK_IS_CRITICAL) { + if (!(prev_flags & CLK_SET_RATE_GATE)) + clk_core_rate_protect(core); + goto out; + } + + ret = clk_core_prepare(core); + if (ret) + goto out; + + ret = clk_core_enable_lock(core); + +out: + clk_prepare_unlock(); + + return ret; +} + /* * clkdev helpers */ diff --git a/drivers/clk/clk.h b/drivers/clk/clk.h index 2d801900cad5..367a0f036b13 100644 --- a/drivers/clk/clk.h +++ b/drivers/clk/clk.h @@ -24,6 +24,7 @@ struct clk_hw *clk_find_hw(const char *dev_id, const char *con_id); #ifdef CONFIG_COMMON_CLK struct clk *clk_hw_create_clk(struct device *dev, struct clk_hw *hw, const char *dev_id, const char *con_id); +int __clk_protect(struct clk *clk); void __clk_put(struct clk *clk); #else /* All these casts to avoid ifdefs in clkdev... */ @@ -33,6 +34,7 @@ clk_hw_create_clk(struct device *dev, struct clk_hw *hw, const char *dev_id, { return (struct clk *)hw; } +static inline int __clk_protect(struct clk *clk) { return 0; } static inline void __clk_put(struct clk *clk) { } #endif
This is a generic implementation of the "protected-clocks" property from the common clock binding. It comes with some caveats: 1) Clocks that have CLK_IS_CRITICAL in their init data are prepared/ enabled before they are attached to the clock tree. protected-clocks are only protected once the clock provider is added, which is generally after all of the clocks it provides have been registered. This leaves a window of opportunity where something could disable or modify the clock, such as a driver running on another CPU, or the clock core itself. There is a comment to this effect in __clk_core_init(): /* * Enable CLK_IS_CRITICAL clocks so newly added critical clocks * don't get accidentally disabled when walking the orphan tree and * reparenting clocks */ Similarly, these clocks will be enabled after they are first reparented, unlike other CLK_IS_CRITICAL clocks. See the comment in clk_core_reparent_orphans_nolock(): /* * We need to use __clk_set_parent_before() and _after() to * to properly migrate any prepare/enable count of the orphan * clock. This is important for CLK_IS_CRITICAL clocks, which * are enabled during init but might not have a parent yet. */ Ideally we could detect protected clocks before they are reparented, but there are two problems with that: i) From the clock core's perspective, hw->init is const. ii) The clock core doesn't see the device_node until __clk_register is called on the first clock. So the only race-free way to detect protected-clocks is to do it in the middle of __clk_register, between when core->flags is initialized and calling __clk_core_init(). That requires scanning the device tree again for each clock, which is part of why I didn't do it that way. 2) __clk_protect needs to be idempotent, for two reasons: i) Clocks with CLK_IS_CRITICAL in their init data are already prepared/enabled, and we don't want to prepare/enable them again. Note that if the clock did not have CLK_SET_RATE_GATE in its init data, it was *not* rate protected during the initial call to clk_core_prepare(). As far as I can tell, none of the other flags affect the internal state of the clock, so they don't need any "parallel reconstruction". ii) of_clk_set_defaults() is called twice for (at least some) clock controllers registered with CLK_OF_DECLARE. It is called first in of_clk_add_provider()/of_clk_add_hw_provider() inside clk_init_cb, and again afterward in of_clk_init(). I think that the second call in of_clk_init() should be removed, but that would require auditing all users of CLK_OF_DECLARE to ensure they called one of the of_clk_add{,_hw}_provider functions. 3) It is not clear specifically which flags should be implied by being in protected-clocks. I took it to mean "this clock is outside of OS control, so don't modify it, and assume it can change at any time". For that reason, I added the following flags: - CLK_SET_RATE_GATE: prevents clk_set_rate() once prepared - CLK_SET_PARENT_GATE: prevents clk_set_parent() once prepared - CLK_GET_RATE_NOCACHE: allows the rate to change behind the OS's back - CLK_GET_ACCURACY_NOCACHE: ditto for the accuracy - CLK_IS_CRITICAL: causes the clock to always be prepared + enabled Some problems I see with this: i) We are still modifying the clock, once, to prepare/enable it. It sounds like this may not be a safe thing to do. But none of the protections in the clock core apply if a clock isn't prepared. Possibly we could prepare and not enable it, assuming that the "enable" step is what actually touches the hardware. However, that would have different semantics from existing CLK_IS_CRITICAL clocks. ii) Protecting the rate protects all ancestor clock rates. This seems like an incredibly big hammer, but if we actually aren't allowed to change the rate of protected clocks, would actually be necessary. Maybe both of these could be solved with a new flag? Otherwise, the only way to prevent the clock core from allowing changes to the clock hardware (and from making the changes itself) is to not register the clock. Unfortunately, that also won't work in this situation, because most of the clocks that I need to protect also have Linux drivers (or their descendants have Linux drivers). It is also unclear how protected-clocks and assigned-clocks should interact. For now, it produces an error, since protected-clocks are handled first. Signed-off-by: Samuel Holland <samuel@sholland.org> --- drivers/clk/clk-conf.c | 54 ++++++++++++++++++++++++++++++++++++++++++ drivers/clk/clk.c | 44 ++++++++++++++++++++++++++++++++++ drivers/clk/clk.h | 2 ++ 3 files changed, 100 insertions(+)