78b435c8db
1185177 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Maxime Ripard
|
78b435c8db |
clk: tegra: super: Add a determine_rate hook
The Tegra super 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: Jonathan Hunter <jonathanh@nvidia.com> Cc: Peter De Schrijver <pdeschrijver@nvidia.com> Cc: Prashant Gaikwad <pgaikwad@nvidia.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: linux-tegra@vger.kernel.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-35-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
4552a852f2 |
clk: tegra: bpmp: Add a determine_rate hook
The Tegra BPMP 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: Jonathan Hunter <jonathanh@nvidia.com> Cc: Peter De Schrijver <pdeschrijver@nvidia.com> Cc: Prashant Gaikwad <pgaikwad@nvidia.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: linux-tegra@vger.kernel.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-34-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
d052f0671f |
clk: stm32: core: Add a determine_rate hook
The STM32 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 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 latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). 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. Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely. Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-33-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
9607beb917 |
clk: socfpga: gate: Add a determine_rate hook
The SoCFGPA gate 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: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-32-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
03b56aa9bf |
clk: renesas: r9a06g032: Add a determine_rate hook
The Renesas r9a06g032 bitselect 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: Geert Uytterhoeven <geert+renesas@glider.be> Cc: linux-renesas-soc@vger.kernel.org Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-31-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
e9b6ea4eb6 |
clk: pxa: Add a determine_rate hook
The PXA "CKEN" 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. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-30-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
90fe6ebf72 |
clk: mediatek: cpumux: Add a determine_rate hook
The Mediatek cpumux 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: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-29-971d5077e7d2@cerno.tech Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
1c2c20dbb5 |
clk: imx: scu: Add a determine_rate hook
The iMX SCU 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. 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: Abel Vesa <abelvesa@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-28-971d5077e7d2@cerno.tech | Reported-by: kernel test robot <lkp@intel.com>: Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
b2252ca68c |
clk: imx: fixup-mux: Add a determine_rate hook
The iMX fixup 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: Abel Vesa <abelvesa@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-27-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
79ef35a944 |
clk: imx: busy: Add a determine_rate hook
The iMX busy 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: Abel Vesa <abelvesa@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-26-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
4d8aa2a3aa |
clk: davinci: da8xx-cfgchip: Add a determine_rate hook
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 <david@lechnology.com> Cc: Sekhar Nori <nsekhar@ti.com> Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-25-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
de9271f24e |
clk: davinci: da8xx-cfgchip: Add a determine_rate hook
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 <david@lechnology.com> Cc: Sekhar Nori <nsekhar@ti.com> Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-24-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
fa2a1931e4 |
clk: wm831x: clkout: Add a determine_rate hook
The WM381x "clkout" 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: patches@opensource.cirrus.com Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-23-971d5077e7d2@cerno.tech | Reported-by: kernel test robot <lkp@intel.com>: Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
538e864f8e |
clk: vc5: clkout: Add a determine_rate hook
The Versaclock5 "clkout" 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: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-22-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
dcba8da50b |
clk: vc5: mux: Add a determine_rate hook
The Versaclock5 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. 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: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-21-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
5ce89dcc68 |
clk: stm32f4: mux: Add a determine_rate hook
The STM32F4 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: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-20-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
67110f5af1 |
clk: si5341: Add a determine_rate hook
The SI5341 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. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-19-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
4cbe64280c |
clk: qoriq: Add a determine_rate hook
The Qoriq mux clocks implement 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. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-18-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
4e382f196a |
clk: lochnagar: Add a determine_rate hook
The lochnagar clocks implement 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. Since there's no upstream device tree using that driver, it's a bit hard to tell if it uses the assigned-clock properties. The binding and its example uses them though, 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 is 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: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Richard Fitzgerald <rf@opensource.cirrus.com> Cc: patches@opensource.cirrus.com Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-17-971d5077e7d2@cerno.tech | Reported-by: kernel test robot <lkp@intel.com>: | Reported-by: kernel test robot <lkp@intel.com>: Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
38bdfb21ed |
clk: lmk04832: clkout: Add a determine_rate hook
The LKM04832 "CLKOUT" 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 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 latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). 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. Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely. Reviewed-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-16-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
f6a01564fc |
clk: k210: mux: Add a determine_rate hook
The K210 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. 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. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-15-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
d0f775d036 |
clk: k210: aclk: Add a determine_rate hook
The K210 ACLK 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. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-14-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
8e3f15601c |
clk: k210: pll: Add a determine_rate hook
The K210 PLL 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. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-13-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
43e8f067db |
clk: cdce706: Add a determine_rate hook
The cdce706 "clkin" 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: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-12-971d5077e7d2@cerno.tech | Reported-by: kernel test robot <lkp@intel.com>: Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
321437f33e |
clk: berlin: div: Add a determine_rate hook
The Berlin2 divider 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. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-11-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
d2e88be308 |
clk: at91: sckc: Add a determine_rate hook
The SAM9x5 slow 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: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-10-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
63ec565301 |
clk: at91: main: Add a determine_rate hook
The SAM9x5 main 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: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-9-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
3876e2d77e |
clk: actions: composite: Add a determine_rate hook for pass clk
The Actions "Pass" 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. 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: "Andreas Färber" <afaerber@suse.de> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: linux-actions@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-8-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
aebddfe2df |
clk: test: Add a determine_rate hook
The single parent clock in our kunit tests implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is not entirely unexpected, since its whole purpose it to have a single parent. When determine_rate is missing, and since CLK_SET_RATE_PARENT is set for all its instances, the default behaviour of the framework will be to forward it to the current parent. This is totally fine as far as the tests are concerned, but we'll start to mandate a determine_rate implementation when set_parent is set, so let's fill it with __clk_mux_determine_rate() which will have the same behavior. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-7-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
9e3943afb2 |
clk: nodrv: Add a determine_rate hook
The nodrv clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. Even though it's a mock clock and the missing function is harmless, we'll start to require a determine_rate implementation when set_parent is set, so let's fill it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-6-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
e2533dad2f |
clk: lan966x: Remove unused round_rate hook
The lan966x driver registers a gck clock with both a determine_rate and a round_rate implementation. Both are equivalent, and are only called by clk_core_determine_round_nolock() which favors determine_rate. Thus, lan966x_gck_round_rate() is never called, so we can just remove it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-5-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
Stephen Boyd
|
33b70fbc4f |
clk: Introduce clk_hw_determine_rate_no_reparent()
Some clock drivers do not want to allow any reparenting on a given clock, but usually do so by not providing any determine_rate implementation. Whenever we call clk_round_rate() or clk_set_rate(), this leads to clk_core_can_round() returning false and thus the rest of the function either forwarding the rate request to its current parent if CLK_SET_RATE_PARENT is set, or just returning the current clock rate. This behaviour happens implicitly, and as we move forward to making a determine_rate implementation required for muxes, we need some way to explicitly opt-in for that behaviour. Fortunately, this is exactly what the clk_core_determine_rate_no_reparent() function is doing, so we can simply make it available to drivers. Cc: Abel Vesa <abelvesa@kernel.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: "Andreas Färber" <afaerber@suse.de> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Chen-Yu Tsai <wenst@chromium.org> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: David Lechner <david@lechnology.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Kishon Vijay Abraham I <kishon@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Luca Ceresoli <luca.ceresoli@bootlin.com> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Markus Schneider-Pargmann <msp@baylibre.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Mikko Perttunen <mperttunen@nvidia.com> Cc: Miles Chen <miles.chen@mediatek.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Paul Cercueil <paul@crapouillou.net> Cc: Peng Fan <peng.fan@nxp.com> Cc: Peter De Schrijver <pdeschrijver@nvidia.com> Cc: Prashant Gaikwad <pgaikwad@nvidia.com> Cc: Richard Fitzgerald <rf@opensource.cirrus.com> Cc: Samuel Holland <samuel@sholland.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Takashi Iwai <tiwai@suse.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Vinod Koul <vkoul@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-actions@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mips@vger.kernel.org Cc: linux-phy@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-sunxi@lists.linux.dev Cc: linux-tegra@vger.kernel.org Cc: NXP Linux Team <linux-imx@nxp.com> Cc: patches@opensource.cirrus.com Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-4-971d5077e7d2@cerno.tech | Reported-by: kernel test robot <lkp@intel.com>: |
||
|
Stephen Boyd
|
1b4e99fda7 |
clk: Move no reparent case into a separate function
We'll need to turn the code in clk_mux_determine_rate_flags() to deal with CLK_SET_RATE_NO_REPARENT into a helper clock drivers will be able to use if they don't want to allow reparenting. Cc: Abel Vesa <abelvesa@kernel.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: "Andreas Färber" <afaerber@suse.de> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Chen-Yu Tsai <wenst@chromium.org> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: David Lechner <david@lechnology.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Kishon Vijay Abraham I <kishon@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Luca Ceresoli <luca.ceresoli@bootlin.com> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Markus Schneider-Pargmann <msp@baylibre.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Mikko Perttunen <mperttunen@nvidia.com> Cc: Miles Chen <miles.chen@mediatek.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Paul Cercueil <paul@crapouillou.net> Cc: Peng Fan <peng.fan@nxp.com> Cc: Peter De Schrijver <pdeschrijver@nvidia.com> Cc: Prashant Gaikwad <pgaikwad@nvidia.com> Cc: Richard Fitzgerald <rf@opensource.cirrus.com> Cc: Samuel Holland <samuel@sholland.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Takashi Iwai <tiwai@suse.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Vinod Koul <vkoul@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-actions@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mips@vger.kernel.org Cc: linux-phy@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-sunxi@lists.linux.dev Cc: linux-tegra@vger.kernel.org Cc: NXP Linux Team <linux-imx@nxp.com> Cc: patches@opensource.cirrus.com Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-3-971d5077e7d2@cerno.tech |
||
|
Maxime Ripard
|
9633b4c17b |
clk: test: Fix type sign of rounded rate variables
clk_round_rate() may return a negative error code, but most of the variables we defined to store its returned value are unsigned. This obviously leads to issues on error. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-2-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org> |
||
|
Maxime Ripard
|
ed046ac74d |
clk: Export clk_hw_forward_rate_request()
Commit |
||
Linus Torvalds
|
ac9a78681b | Linux 6.4-rc1 | ||
|
Linus Torvalds
|
f085df1be6 |
Disable building BPF based features by default for v6.4.
We need to better polish building with BPF skels, so revert back to
making it an experimental feature that has to be explicitely enabled
using BUILD_BPF_SKEL=1.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQR2GiIUctdOfX2qHhGyPKLppCJ+JwUCZFbCXwAKCRCyPKLppCJ+
J7cHAP97erKY4hBXArjpfzcvpFmboh/oqhbTLntyIpS6TEnOyQEAyervAPGIjQYC
DCo4foyXmOWn3dhNtK9M+YiRl3o2SgQ=
=7G78
-----END PGP SIGNATURE-----
Merge tag 'perf-tools-for-v6.4-3-2023-05-06' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
Pull perf tool updates from Arnaldo Carvalho de Melo:
"Third version of perf tool updates, with the build problems with with
using a 'vmlinux.h' generated from the main build fixed, and the bpf
skeleton build disabled by default.
Build:
- Require libtraceevent to build, one can disable it using
NO_LIBTRACEEVENT=1.
It is required for tools like 'perf sched', 'perf kvm', 'perf
trace', etc.
libtraceevent is available in most distros so installing
'libtraceevent-devel' should be a one-time event to continue
building perf as usual.
Using NO_LIBTRACEEVENT=1 produces tooling that is functional and
sufficient for lots of users not interested in those libtraceevent
dependent features.
- Allow Python support in 'perf script' when libtraceevent isn't
linked, as not all features requires it, for instance Intel PT does
not use tracepoints.
- Error if the python interpreter needed for jevents to work isn't
available and NO_JEVENTS=1 isn't set, preventing a build without
support for JSON vendor events, which is a rare but possible
condition. The two check error messages:
$(error ERROR: No python interpreter needed for jevents generation. Install python or build with NO_JEVENTS=1.)
$(error ERROR: Python interpreter needed for jevents generation too old (older than 3.6). Install a newer python or build with NO_JEVENTS=1.)
- Make libbpf 1.0 the minimum required when building with out of
tree, distro provided libbpf.
- Use libsdtc++'s and LLVM's libcxx's __cxa_demangle, a portable C++
demangler, add 'perf test' entry for it.
- Make binutils libraries opt in, as distros disable building with it
due to licensing, they were used for C++ demangling, for instance.
- Switch libpfm4 to opt-out rather than opt-in, if libpfm-devel (or
equivalent) isn't installed, we'll just have a build warning:
Makefile.config:1144: libpfm4 not found, disables libpfm4 support. Please install libpfm4-dev
- Add a feature test for scandirat(), that is not implemented so far
in musl and uclibc, disabling features that need it, such as
scanning for tracepoints in /sys/kernel/tracing/events.
perf BPF filters:
- New feature where BPF can be used to filter samples, for instance:
$ sudo ./perf record -e cycles --filter 'period > 1000' true
$ sudo ./perf script
perf-exec 2273949 546850.708501: 5029 cycles: ffffffff826f9e25 finish_wait+0x5 ([kernel.kallsyms])
perf-exec 2273949 546850.708508: 32409 cycles: ffffffff826f9e25 finish_wait+0x5 ([kernel.kallsyms])
perf-exec 2273949 546850.708526: 143369 cycles: ffffffff82b4cdbf xas_start+0x5f ([kernel.kallsyms])
perf-exec 2273949 546850.708600: 372650 cycles: ffffffff8286b8f7 __pagevec_lru_add+0x117 ([kernel.kallsyms])
perf-exec 2273949 546850.708791: 482953 cycles: ffffffff829190de __mod_memcg_lruvec_state+0x4e ([kernel.kallsyms])
true 2273949 546850.709036: 501985 cycles: ffffffff828add7c tlb_gather_mmu+0x4c ([kernel.kallsyms])
true 2273949 546850.709292: 503065 cycles: 7f2446d97c03 _dl_map_object_deps+0x973 (/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
- In addition to 'period' (PERF_SAMPLE_PERIOD), the other
PERF_SAMPLE_ can be used for filtering, and also some other sample
accessible values, from tools/perf/Documentation/perf-record.txt:
Essentially the BPF filter expression is:
<term> <operator> <value> (("," | "||") <term> <operator> <value>)*
The <term> can be one of:
ip, id, tid, pid, cpu, time, addr, period, txn, weight, phys_addr,
code_pgsz, data_pgsz, weight1, weight2, weight3, ins_lat, retire_lat,
p_stage_cyc, mem_op, mem_lvl, mem_snoop, mem_remote, mem_lock,
mem_dtlb, mem_blk, mem_hops
The <operator> can be one of:
==, !=, >, >=, <, <=, &
The <value> can be one of:
<number> (for any term)
na, load, store, pfetch, exec (for mem_op)
l1, l2, l3, l4, cxl, io, any_cache, lfb, ram, pmem (for mem_lvl)
na, none, hit, miss, hitm, fwd, peer (for mem_snoop)
remote (for mem_remote)
na, locked (for mem_locked)
na, l1_hit, l1_miss, l2_hit, l2_miss, any_hit, any_miss, walk, fault (for mem_dtlb)
na, by_data, by_addr (for mem_blk)
hops0, hops1, hops2, hops3 (for mem_hops)
perf lock contention:
- Show lock type with address.
- Track and show mmap_lock, siglock and per-cpu rq_lock with address.
This is done for mmap_lock by following the current->mm pointer:
$ sudo ./perf lock con -abl -- sleep 10
contended total wait max wait avg wait address symbol
...
16344 312.30 ms 2.22 ms 19.11 us ffff8cc702595640
17686 310.08 ms 1.49 ms 17.53 us ffff8cc7025952c0
3 84.14 ms 45.79 ms 28.05 ms ffff8cc78114c478 mmap_lock
3557 76.80 ms 68.75 us 21.59 us ffff8cc77ca3af58
1 68.27 ms 68.27 ms 68.27 ms ffff8cda745dfd70
9 54.53 ms 7.96 ms 6.06 ms ffff8cc7642a48b8 mmap_lock
14629 44.01 ms 60.00 us 3.01 us ffff8cc7625f9ca0
3481 42.63 ms 140.71 us 12.24 us ffffffff937906ac vmap_area_lock
16194 38.73 ms 42.15 us 2.39 us ffff8cd397cbc560
11 38.44 ms 10.39 ms 3.49 ms ffff8ccd6d12fbb8 mmap_lock
1 5.43 ms 5.43 ms 5.43 ms ffff8cd70018f0d8
1674 5.38 ms 422.93 us 3.21 us ffffffff92e06080 tasklist_lock
581 4.51 ms 130.68 us 7.75 us ffff8cc9b1259058
5 3.52 ms 1.27 ms 703.23 us ffff8cc754510070
112 3.47 ms 56.47 us 31.02 us ffff8ccee38b3120
381 3.31 ms 73.44 us 8.69 us ffffffff93790690 purge_vmap_area_lock
255 3.19 ms 36.35 us 12.49 us ffff8d053ce30c80
- Update default map size to 16384.
- Allocate single letter option -M for --map-nr-entries, as it is
proving being frequently used.
- Fix struct rq lock access for older kernels with BPF's CO-RE
(Compile once, run everywhere).
- Fix problems found with MSAn.
perf report/top:
- Add inline information when using --call-graph=fp or lbr, as was
already done to the --call-graph=dwarf callchain mode.
- Improve the 'srcfile' sort key performance by really using an
optimization introduced in 6.2 for the 'srcline' sort key that
avoids calling addr2line for comparision with each sample.
perf sched:
- Make 'perf sched latency/map/replay' to use "sched:sched_waking"
instead of "sched:sched_waking", consistent with 'perf record'
since
|
||
|
Linus Torvalds
|
17784de648 |
A single fix for debugobjects:
The recent fix to ensure atomicity of lookup and allocation inadvertently broke the pool refill mechanism, so that debugobject OOMs now in certain situations. The reason is that the functions which got updated no longer invoke debug_objecs_init(), which is now the only place to care about refilling the tracking object pool. Restore the original behaviour by adding explicit refill opportunities to those places. -----BEGIN PGP SIGNATURE----- iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmRWoFATHHRnbHhAbGlu dXRyb25peC5kZQAKCRCmGPVMDXSYocNID/9e1fU2Nf32woHokzBGgARKb69Kl/hb 6yVdMpOnZtxmluheJLnqCWI4WbAB6NjulEMFv+KkwRZ+QndBKVEo8NMZ9RjbXDBb HEehI6DvsqRDjaytOLEZj+/8afcZ7bUBKk7JuUK+y5B1gZViazfp1eF3hpiKsIV9 aowpH6c9lL/9sPgFe2qpp21MUmNTUQbHpz0vbYC0QjqSEU2zTlu8p//P6VLA3xpl qoh8Gu5qo/L8lPspN2v8TRVXdiqH67J+KpbGO9IuUQWYPQqFdc6WchhHwomAk8nr Nyn9Q1Lred96pTdW3B0Cumnxuf0VPt4X/uQxPSP0kCo/h0Q0Mh6fq59Z66H/Mhjk TAvM52w3VzfTmQB6WgaCD1HyRRqIK5Nd+XqXnenCkHN4kjmGXNLg9MUGxua5CVgF iQTSRYtN18rF9OevDOFGzsEig2RN1JFi9MnJg9Q/L8SoDUn5ZUfhPaSA/HcOBnSe m+9aeRxlb0hAP7+upFKsJkDYzJTtbP6LSx6qqZMyQWqYdsUVHpdiPtJpXb7mLIqQ wo83i/Ohq8+dF6ykd89ZcKJ8vLBrnE1rPFKKmvS5ov1eRt/hZbtR3tmMviCNna0M 2nrJE2fKClbs8Dmc6NNboJdz51ASgZEi32XmdFkATiuZqiD1id7ne0f85ju7DHD9 sOjfo4ZtIKD/Fw== =/0Kc -----END PGP SIGNATURE----- Merge tag 'core-debugobjects-2023-05-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull debugobjects fix from Thomas Gleixner: "A single fix for debugobjects: The recent fix to ensure atomicity of lookup and allocation inadvertently broke the pool refill mechanism, so that debugobject OOMs now in certain situations. The reason is that the functions which got updated no longer invoke debug_objecs_init(), which is now the only place to care about refilling the tracking object pool. Restore the original behaviour by adding explicit refill opportunities to those places" * tag 'core-debugobjects-2023-05-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: debugobject: Ensure pool refill (again) |
||
|
Linus Torvalds
|
6f69c98181 |
This push fixes the following problems:
- A long-standing bug in crypto_engine. - A buggy but harmless check in the sun8i-ss driver. - A regression in the CRYPTO_USER interface. -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEn51F/lCuNhUwmDeSxycdCkmxi6cFAmRQ5RgACgkQxycdCkmx i6dA1hAAsdP9Nx6d1ux0KYCI9FsnjU06JITzEA/LmzMXqxfElUzatZswaQuE8gSd SoUNuWk5PiKEK5BIJRdKNyKc+kElxCewknEbpvbHi3QGs/BZyfPuDf17gPnNaxsA KxA2WLU9XBaI0mt44mPuX5aLlCMnJ/RFhi7I5lJ3H31V6FU75BVE3DOCSxZNNipN eWfG1c2f3K9Q0Qc3CSxUkzvNKTy+YW+i/fwdisToX2Zj/jduWmUi8PcbQQIX5+PX Dch1LxnTu/l+Dn5PBICmhK8B86oTTCF83FOYX2f7ng4YuZ95gN/gn3/s5U4UkkKl n74rupfhKkUHFeWS93ToC0qKniuN+QuPA8GumBFYjywn2gA7CS1BSV3+++ryJxRO q9RXtHU7R7IXQGn5IKCqwzcBHrtnxUlIptMV2VH3Sbixtzn5QW0m10/lHHNKIy5E laXr+dr+uBcL5+mSDYvsRbaQxfQ9G5wGvelnl7c1hXEG1VV6O5pVXLTlw81U7K3u 38m7dQl1/A3IetYpMrFcqhiGt0T84ttJerLaQRLNZCeNSAB70Gq/eSSSK4uyHl7I pVb2eiLE84NCUZfemD8CER9Zv6z+kFDEO6xpLeBOd6BAzfYJXaTaquLnERh/bduo WXnGlrDv6W+N+w4nP6AQ711mDqP5vMdLeSwbUfJChqeNHmM8nG8= =9Us7 -----END PGP SIGNATURE----- Merge tag 'v6.4-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: - A long-standing bug in crypto_engine - A buggy but harmless check in the sun8i-ss driver - A regression in the CRYPTO_USER interface * tag 'v6.4-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: api - Fix CRYPTO_USER checks for report function crypto: engine - fix crypto_queue backlog handling crypto: sun8i-ss - Fix a test in sun8i_ss_setup_ivs() |
||
|
Linus Torvalds
|
63342b1dd5 |
9 smb3 client fixes, mostly DFS or reconnect related
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAmRWpDAACgkQiiy9cAdy
T1Gm1gv+IZhwnTNWJ5OLaFKVjKsM5flAaj4To15hFxHDUgfkTlG+c0T2jbrjQZq5
OEdnXn/zgVrq/JTU6TIrMA6netmkNKEvEW/MPb5sKgbXdkM8dM8AkCYjs2WvaHLV
IBrmo9URUr0/I0rBMCvEFHGQvvggAizKrkvqVZq1DmQ+8Y7WXMWBuINux6i2+NmJ
uDgBx/FcEIqpc0i5STD7hQ3kZ/MnBOVcd4lxUAZk6GtpiKZe/u6veWpyt9FqD8N7
AXQhhfoLXEPNda1N5P1tfCIsWO+70XzgF5eetr95/71f3MIWPNbdOyJ9MFyr8DzV
dUA8uReV8RVF7uCEC6AnXmOlteZ855trzpk8EK54ey5fmcnelzMLsIKNbzxgcJZP
y4EDNbP57b+G28SnWTLsdXfrBxicO7ExBPOiys2hfJ3VCC5xSkN04IDlRnsgZKiE
Tbwo/eaZy31Z6EN5BiqjFI/RgNZJaEdl9GeGZJFum3AGB+wKDSWl5Es77i11PBuI
5qZgahwT
=ZsoO
-----END PGP SIGNATURE-----
Merge tag '6.4-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs fixes from Steve French:
"smb3 client fixes, mostly DFS or reconnect related:
- Two DFS connection sharing fixes
- DFS refresh fix
- Reconnect fix
- Two potential use after free fixes
- Also print prefix patch in mount debug msg
- Two small cleanup fixes"
* tag '6.4-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6:
cifs: Remove unneeded semicolon
cifs: fix sharing of DFS connections
cifs: avoid potential races when handling multiple dfs tcons
cifs: protect access of TCP_Server_Info::{origin,leaf}_fullpath
cifs: fix potential race when tree connecting ipc
cifs: fix potential use-after-free bugs in TCP_Server_Info::hostname
cifs: print smb3_fs_context::source when mounting
cifs: protect session status check in smb2_reconnect()
SMB3.1.1: correct definition for app_instance_id create contexts
|
||
|
Linus Torvalds
|
d6b8a8c49a |
A couple more patches that would be good to get into -rc1.
- Revert an i.MX patch that's causing video failures because division
math goes sideways
- Fix a clang + W=1 build isue where FIELD_PREP() is taking a 32-bit
variable instead of the usual u64 type
- Fix a Kconfig bug in the StarFive JH7110 clk config that selects a
reset controller when it can't be selected
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAmRW7qARHHNib3lkQGtl
cm5lbC5vcmcACgkQrQKIl8bklSU8gA/8Dee5F/zZR+Y7TJGld2ZF5gTjo+5vWrPP
SQ4FTCSZwnslrYcESXL+tfKxGv4JaP+bbWfufbbBYAlapNQZchSnRurg0rvYCIc2
s9NeUbLvPhxJTaBJIOoUzOfzezvPpS9+eEnT6goyvrWrYBz+wolTrsOzI6t2ocyb
9KpBEiaqAUSOmno6mNmqNg48UvBytgtXBnlC3YsqLlKuBZcRBrK/nHO+dUIqb2kO
s0fbbnNI2Mal0e3Se25ehW803fl+OhnxshHO4EO+aRvCLhXINgyapFNR2vk1woN2
UM38va+BPyzaI9goXcxMN5JROxGZFTmHMYtrqgimvFwxVDnHdz2jdokaY0fLhAMV
mN5Y+J1XBdNui4Pz/iWzldkPWULtbLTCZZQFl1lbAdBcvPSQC+hIcQEFKxg0O4rk
d0+B3a2SPfK1X5Ebl+BtOogbTGr616zVHgiiHeU0vxxFbqXboGh+iKJJdvtHA4WF
t/y4gH3cx67NneUFMihNs+UqVSVnE6N1+EghTzAubnEIz3ONIQDyvWuTNagDZBWH
QRMJz51691OGuSAW6lw9Nnfe0qNFiSzQpJptBT1bJ2GvTzOUI8izNLZ0ah/effuR
avHhYGkf7DYggyldEf5eL/iVqUTJ1JYKpRdcuyfLAg4q0UPmRP43n4KdTtZ98wC3
UdusEJ8EqDc=
=IxvN
-----END PGP SIGNATURE-----
Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"A couple more patches that would be good to get into -rc1:
- Revert an i.MX patch that's causing video failures because division
math goes sideways
- Fix a clang + W=1 build isue where FIELD_PREP() is taking a 32-bit
variable instead of the usual u64 type
- Fix a Kconfig bug in the StarFive JH7110 clk config that selects a
reset controller when it can't be selected"
* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: starfive: Fix RESET_STARFIVE_JH7110 can't be selected in a specified case
clk: sp7021: Adjust width of _m in HWM_FIELD_PREP()
Revert "clk: imx: composite-8m: Add support to determine_rate"
|
||
|
Linus Torvalds
|
1c1094e47e |
- mailbox api: allow direct registration to a channel
Convert omap and pcc to use mbox_bind_client - omap and hi6220 : use of_property_read_bool - test: fix double-free and use spinlock header - rockchip and bcm-pdc: drop of_match_ptr - mpfs: change config symbol - mediatek gce: support MT6795 - qcom apcs: consolidate of_device_id support IPQ9574 -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6EwehDt/SOnwFyTyf9lkf8eYP5UFAmRWXwYACgkQf9lkf8eY P5V11Q/9G2V2V/QO6EJm8JQ6ElkO+cLeZezmyAhlt3l7n2B5WjEdnKX2nxOYmgZl qb+tYFJO7cd+lpMMTWz4PfOZbedkhrGXwzV8OMzXHJHfOdy3oojw8NYXY7IXdwsy jhik8jYSUx2vHYCTCbAT0SgNLWJHE+RMzFjg01Wb49zIqJf9kbw8RfmWItKGLBJt 0ePSYW2o7LckMf3KSVV3YxfTlvX6Wb0rE0HXv/YI17XtDWT/RlpHb9rVvPWcpKfI wZjQ49wxjtpsilxAQijcT+gE2wmvx62S1HeSSwE7JZ/7k4Ihg269rUa3p0Dp3dcA RLyEhrLt3KWAWYWDXvsGVhaJvrtHI0BMA1Pb3C+qnjdcySs8AZgQbGTtI3RPOiuq 3VCshYVZMEbVoXZOHFbov0e6pyBX5dLqU8W3FhfAVunovj/d7/+74h1uP6ecJjhP +DazIWSc20ATWUaD+UrjPhaGsNwEGceiJiY6nHhnzWZlu2K+2UXRlSrL/iAydvaj SRJeqHiY12fGPGVOScpCMylAGsa+VI+oA61JlMfjLvuyL4qSwNwZGpmCUlIod2AJ 8vUGw254XMr5CiZ4u/D/cyi+7gJ4la53xNkNZIfFs7cP+gbCygaCHDy11bzQa+i1 /sLR9voYIp0Woljds5a6L+o2bP5hkf/Uf+6WKEU8uaW98f5tA14= =NHj4 -----END PGP SIGNATURE----- Merge tag 'mailbox-v6.4' of git://git.linaro.org/landing-teams/working/fujitsu/integration Pull mailbox updates from Jassi Brar: - mailbox api: allow direct registration to a channel and convert omap and pcc to use mbox_bind_client - omap and hi6220 : use of_property_read_bool - test: fix double-free and use spinlock header - rockchip and bcm-pdc: drop of_match_ptr - mpfs: change config symbol - mediatek gce: support MT6795 - qcom apcs: consolidate of_device_id and support IPQ9574 * tag 'mailbox-v6.4' of git://git.linaro.org/landing-teams/working/fujitsu/integration: dt-bindings: mailbox: qcom: add compatible for IPQ9574 SoC mailbox: qcom-apcs-ipc: do not grow the of_device_id dt-bindings: mailbox: qcom,apcs-kpss-global: use fallbacks for few variants dt-bindings: mailbox: mediatek,gce-mailbox: Add support for MT6795 mailbox: mpfs: convert SOC_MICROCHIP_POLARFIRE to ARCH_MICROCHIP_POLARFIRE mailbox: bcm-pdc: drop of_match_ptr for ID table mailbox: rockchip: drop of_match_ptr for ID table mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write() mailbox: mailbox-test: Explicitly include header for spinlock support mailbox: Use of_property_read_bool() for boolean properties mailbox: pcc: Use mbox_bind_client mailbox: omap: Use mbox_bind_client mailbox: Allow direct registration to a channel |
||
|
Linus Torvalds
|
03e5cb7b50 |
for-6.4/io_uring-2023-05-07
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmRXkp8QHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpsH3EADZ4ex4vvc2/giYjRYTdyda00GIdYGiSZaZ
OBW59OBYJfDjsS99Z2U4638shyqM3rA6BwzvWD6hPUTShD7PUddIKDaanpCYBs+x
GhcDhzeJxARjsp/5qZPQ4r3Hdp+kWRnOFu1BSniCEdWt43J6AOm0l5duuNxl1db5
Jz+BkSgF1pICAVB5YfSPDShyFiDfc0qcv3rHZo/rVRjwmX3x4x+OVr97zbZInnH4
fm2vcv2e3Dc8uQEB0XFEyBWNeC8hdhTNe60t1y3MlILaPjHrQlzl5lkQFZ9dtLG6
/FDK+bD6Ex8t6SQnnQGrLa9q4vQYA6zlT5u/wdvzAkakmrSxt6phf23U1TbyZSQ8
clSg6MSuyJAW7YhiT3OqAsNMvBZ5g/nKHjLxfkAe86N9YIrMebZW9GDF+fWf0q0K
em7O4XPehjkCXKclCInMv2bkv+/pncrd84D7Jt3OmCPljBL6oXfWF3vJJQ6FaY+t
G3tNxl1hMHqwX8uaaSqyeuMYAEYizZa+ebMmHJwm/151d0EKylAOh3i6O1e4bpk3
Kn5irF6pfTV1g1TcmY3fOwNgMffcHc9Y4E8bXxMJAN9WiHDuopgn2C9+MrJ+KRrx
pLN7VD9UK/5yFzHSMBhyM8lm0/oTIhfTVgb+WyuHmJLcRhAnyNy9RrIBhSD0AoH+
UMyOexZR8w==
=l7Mo
-----END PGP SIGNATURE-----
Merge tag 'for-6.4/io_uring-2023-05-07' of git://git.kernel.dk/linux
Pull more io_uring updates from Jens Axboe:
"Nothing major in here, just two different parts:
- A small series from Breno that enables passing the full SQE down
for ->uring_cmd().
This is a prerequisite for enabling full network socket operations.
Queued up a bit late because of some stylistic concerns that got
resolved, would be nice to have this in 6.4-rc1 so the dependent
work will be easier to handle for 6.5.
- Fix for the huge page coalescing, which was a regression introduced
in the 6.3 kernel release (Tobias)"
* tag 'for-6.4/io_uring-2023-05-07' of git://git.kernel.dk/linux:
io_uring: Remove unnecessary BUILD_BUG_ON
io_uring: Pass whole sqe to commands
io_uring: Create a helper to return the SQE size
io_uring/rsrc: check for nonconsecutive pages
|
||
Arnaldo Carvalho de Melo
|
9a2d5178b9 |
Revert "perf build: Make BUILD_BPF_SKEL default, rename to NO_BPF_SKEL"
This reverts commit
|
||
|
Arnaldo Carvalho de Melo
|
c3e6df97fa |
Revert "perf build: Warn for BPF skeletons if endian mismatches"
This reverts commit
|
||
|
Linus Torvalds
|
fc4354c6e5 |
Reinstate the dmapool changes which were accidentally removed by
|
||
|
Linus Torvalds
|
706ce3caea |
Five hotfixes. Three are cc:stable, two pertain to post-6.3 merge window
changes. -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCZFaSnAAKCRDdBJ7gKXxA jskTAPwIkL6xVMIEdtWfQNIy751o0onzfOQAIWgM3dSL83cMJQEA5OXxXt4LjrJw 4q0zf4GLYXjMjhnfYr8zXF39y05iyQA= =nIhV -----END PGP SIGNATURE----- Merge tag 'mm-hotfixes-stable-2023-05-06-10-45' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull hotfixes from Andrew Morton: "Five hotfixes. Three are cc:stable, two pertain to merge window changes" * tag 'mm-hotfixes-stable-2023-05-06-10-45' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: afs: fix the afs_dir_get_folio return value nilfs2: do not write dirty data after degenerating to read-only mm: do not reclaim private data from pinned page nilfs2: fix infinite loop in nilfs_mdt_get_block() mm/mmap/vma_merge: always check invariants |
||
Keith Busch
|
da9619a30e |
dmapool: link blocks across pages
The allocated dmapool pages are never freed for the lifetime of the pool.
There is no need for the two level list+stack lookup for finding a free
block since nothing is ever removed from the list. Just use a simple
stack, reducing time complexity to constant.
The implementation inserts the stack linking elements and the dma handle
of the block within itself when freed. This means the smallest possible
dmapool block is increased to at most 16 bytes to accommodate these
fields, but there are no exisiting users requesting a dma pool smaller
than that anyway.
Removing the list has a significant change in performance. Using the
kernel's micro-benchmarking self test:
Before:
# modprobe dmapool_test
dmapool test: size:16 blocks:8192 time:57282
dmapool test: size:64 blocks:8192 time:172562
dmapool test: size:256 blocks:8192 time:789247
dmapool test: size:1024 blocks:2048 time:371823
dmapool test: size:4096 blocks:1024 time:362237
After:
# modprobe dmapool_test
dmapool test: size:16 blocks:8192 time:24997
dmapool test: size:64 blocks:8192 time:26584
dmapool test: size:256 blocks:8192 time:33542
dmapool test: size:1024 blocks:2048 time:9022
dmapool test: size:4096 blocks:1024 time:6045
The module test allocates quite a few blocks that may not accurately
represent how these pools are used in real life. For a more marco level
benchmark, running fio high-depth + high-batched on nvme, this patch shows
submission and completion latency reduced by ~100usec each, 1% IOPs
improvement, and perf record's time spent in dma_pool_alloc/free were
reduced by half.
[kbusch@kernel.org: push new blocks in ascending order]
Link: https://lkml.kernel.org/r/20230221165400.1595247-1-kbusch@meta.com
Link: https://lkml.kernel.org/r/20230126215125.4069751-12-kbusch@meta.com
Fixes:
|
||
|
Keith Busch
|
8ecc369554 |
dmapool: don't memset on free twice
If debug is enabled, dmapool will poison the range, so no need to clear it
to 0 immediately before writing over it.
Link: https://lkml.kernel.org/r/20230126215125.4069751-11-kbusch@meta.com
Fixes:
|
||
|
Keith Busch
|
cc669954ab |
dmapool: simplify freeing
The actions for busy and not busy are mostly the same, so combine these
and remove the unnecessary function. Also, the pool is about to be freed
so there's no need to poison the page data since we only check for poison
on alloc, which can't be done on a freed pool.
Link: https://lkml.kernel.org/r/20230126215125.4069751-10-kbusch@meta.com
Fixes:
|