kernel/linux.git/drivers/clk/davinci, branch v6.12.80

clk: davinci: Add NULL check in davinci_lpsc_clk_register()

2025-08-15T10:13:50+00:00

[ Upstream commit 13de464f445d42738fe18c9a28bab056ba3a290a ] devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated. Fixes: c6ed4d734bc7 ("clk: davinci: New driver for davinci PSC clocks") Signed-off-by: Henry Martin Link: https://lore.kernel.org/r/20250401131341.26800-1-bsdhenrymartin@gmail.com Reviewed-by: David Lechner Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin

clk:davinci: make use of dev_err_cast_probe()

2024-08-28T20:11:21+00:00

Using dev_err_cast_probe() to simplify the code. Signed-off-by: Yuesong Li Link: https://lore.kernel.org/r/20240828073515.950677-1-liyuesong@vivo.com Reviewed-by: David Lechner Signed-off-by: Stephen Boyd

da8xx-cfgchip.c: replace of_node_put with __free improves cleanup

2024-07-29T23:12:50+00:00

The use of the __free function allows the cleanup to be based on scope instead of on another function called later. This makes the cleanup automatic and less susceptible to errors later. This code was compiled without errors or warnings. Signed-off-by: David Hunter Link: https://lore.kernel.org/r/20240720152447.311442-1-david.hunter.linux@gmail.com Reviewed-by: David Lechner Signed-off-by: Stephen Boyd

clk: davinci: da8xx-cfgchip: Initialize clk_init_data before use

2024-07-18T20:33:01+00:00

The flag attribute of the struct clk_init_data isn't initialized before the devm_clk_hw_register() call. This can lead to unexpected behavior during registration. Initialize the entire clk_init_data to zero at declaration. Cc: stable@vger.kernel.org Fixes: 58e1e2d2cd89 ("clk: davinci: cfgchip: Add TI DA8XX USB PHY clocks") Signed-off-by: Bastien Curutchet Reviewed-by: David Lechner Link: https://lore.kernel.org/r/20240718115534.41513-1-bastien.curutchet@bootlin.com Signed-off-by: Stephen Boyd

clk: Use device_get_match_data()

2023-10-24T03:16:21+00:00

Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20231006213959.334439-1-robh@kernel.org Reviewed-by: Dmitry Baryshkov #msm part Acked-by: Krzysztof Kozlowski # Samsung Acked-by: David Lechner Acked-by: Chanwoo Choi Acked-by: Charles Keepax Reviewed-by: Bjorn Andersson Signed-off-by: Stephen Boyd

clk: da8xx: clk48: Switch to determine_rate

2023-06-09T01:39:34+00:00

The TI DA8xx USB0 clk48 clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent. However, It's hard to tell whether it's been done on purpose or not. Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on. Cc: David Lechner Cc: Sekhar Nori Acked-by: David Lechner Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-57-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd

clk: davinci: da8xx-cfgchip: Add a determine_rate hook

2023-06-09T01:39:28+00:00

The Davinci DA8xxx cfgchip "clk48" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Cc: David Lechner Cc: Sekhar Nori Acked-by: David Lechner Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-25-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd

clk: davinci: da8xx-cfgchip: Add a determine_rate hook

2023-06-09T01:39:28+00:00

The Davinci DA8xxx cfgchip mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. However, the upstream device trees seem to use assigned-clock-parents on that clock to force the parent at boot time, so it's likely that the author intent was to force the parent through the device tree and prevent any reparenting but through an explicit call to clk_set_parent(). This case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. Cc: David Lechner Cc: Sekhar Nori Acked-by: David Lechner Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-24-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd

clk: remove davinci dm3xx drivers

2023-01-12T09:53:12+00:00

The davinci dm3xx machines are all removed, so the clk driver is no longer needed. The da8xx platforms are now using DT exclusively, so those drivers remain untouched. Reviewed-by: David Lechner Acked-by: Linus Walleij Acked-by: Bartosz Golaszewski Acked-by: Stephen Boyd Signed-off-by: Arnd Bergmann

ARM: davinci: drop DAVINCI_DMxxx references

2023-01-12T09:53:12+00:00

Support for all the dm3xx/dm64xx SoCs is no longer available, so drop all other references to those. Acked-by: Stephen Boyd Signed-off-by: Arnd Bergmann