aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-09-15mailbox: apple: Implement flush() operationHector Martin1-0/+27
This allows clients to use the atomic-safe mailbox API style. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2022-09-15tools/power/x86/intel-speed-select: Fix cpu count for TDP level displayZhang Rui1-1/+1
In the function isst_ctdp_display_information(), call to the function get_cpu_count() is using get_physical_die_id() instead of get_physical_package_id(). This will result in wrong display of CPU count in that level. Signed-off-by: Zhang Rui <rui.zhang@intel.com> [ Srinivas Pandruvada: fixed subject and change log ] Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2022-09-15io_uring/msg_ring: check file type before puttingJens Axboe1-1/+2
If we're invoked with a fixed file, follow the normal rules of not calling io_fput_file(). Fixed files are permanently registered to the ring, and do not need putting separately. Cc: stable@vger.kernel.org Fixes: aa184e8671f0 ("io_uring: don't attempt to IOPOLL for MSG_RING requests") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-09-15clk: tests: Add missing test case for rangesMaxime Ripard1-0/+53
Let's add a test on the rate range after a reparenting. This fails for now, but it's worth having it to document the corner cases we don't support yet. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-26-maxime@cerno.tech Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: qcom: clk-rcg2: Take clock boundaries into consideration for gfx3dMaxime Ripard1-0/+9
The gfx3d clock is hand-crafting its own clk_rate_request in clk_gfx3d_determine_rate to pass to the parent of that clock. However, since the clk_rate_request is zero'd at creation, it will have a max_rate of 0 which will break any code depending on the clock boundaries. That includes the recent commit 948fb0969eae ("clk: Always clamp the rounded rate") which will clamp the rate given to clk_round_rate() to the current clock boundaries. For the gfx3d clock, it means that since both the min_rate and max_rate fields are set at zero, clk_round_rate() now always return 0. Let's initialize the min_rate and max_rate fields properly for that clock. Fixes: 948fb0969eae ("clk: Always clamp the rounded rate") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-25-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Introduce the clk_hw_get_rate_range functionMaxime Ripard2-0/+18
Some clock providers are hand-crafting their clk_rate_request, and need to figure out the current boundaries of their clk_hw to fill it properly. Let's create such a function for clock providers. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-24-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Zero the clk_rate_request structureMaxime Ripard1-0/+2
In order to make sure we don't carry anything over from an already existing clk_rate_request pointer we would pass to clk_core_init_rate_req(), let's zero the entire structure before initializing it. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-23-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Stop forwarding clk_rate_requests to the parentMaxime Ripard7-16/+279
If the clock cannot modify its rate and has CLK_SET_RATE_PARENT, clk_mux_determine_rate_flags(), clk_core_round_rate_nolock() and a number of drivers will forward the clk_rate_request to the parent clock. clk_core_round_rate_nolock() will pass the pointer directly, which means that we pass a clk_rate_request to the parent that has the rate, min_rate and max_rate of the child, and the best_parent_rate and best_parent_hw fields will be relative to the child as well, so will point to our current clock and its rate. The most common case for CLK_SET_RATE_PARENT is that the child and parent clock rates will be equal, so the rate field isn't a worry, but the other fields are. Similarly, if the parent clock driver ever modifies the best_parent_rate or best_parent_hw, this will be applied to the child once the call to clk_core_round_rate_nolock() is done. best_parent_hw is probably not going to be a valid parent, and best_parent_rate might lead to a parent rate change different to the one that was initially computed. clk_mux_determine_rate_flags() and the affected drivers will copy the request before forwarding it to the parents, so they won't be affected by the latter issue, but the former is still going to be there and will lead to erroneous data and context being passed to the various clock drivers in the same sub-tree. Let's create two new functions, clk_core_forward_rate_req() and clk_hw_forward_rate_request() for the framework and the clock providers that will copy a request from a child clock and update the context to match the parent's. We also update the relevant call sites in the framework and drivers to use that new function. Let's also add a test to make sure we avoid regressions there. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-22-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Constify clk_has_parent()Maxime Ripard2-2/+2
clk_has_parent() doesn't modify the clocks being passed, so let's make it const. Suggested-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-21-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Introduce clk_core_has_parent()Maxime Ripard2-15/+65
We will need to know if a clk_core pointer has a given parent in other functions, so let's create a clk_core_has_parent() function that clk_has_parent() will call into. For good measure, let's add some unit tests as well to make sure it works properly. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-20-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> [sboyd@kernel.org: Move tmp declaration, fix conditional to check for current parent] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Switch from __clk_determine_rate to clk_core_round_rate_nolockMaxime Ripard1-3/+10
clk_mux_determine_rate_flags() will call into __clk_determine_rate() with a clk_hw pointer, while it has access to the clk_core pointer already. This leads to back and forth between clk_hw and clk_core, while __clk_determine_rate will only call clk_core_round_rate_nolock() with the clk_core pointer it retrieved from the clk_hw. Let's simplify things a bit by calling into clk_core_round_rate_nolock directly. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-19-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Add our request boundaries in clk_core_init_rate_reqMaxime Ripard1-6/+1
The expectation is that a new clk_rate_request is initialized through a call to clk_core_init_rate_req(). However, at the moment it only fills the parent rate and clk_hw pointer, but omits the other fields such as the clock rate boundaries. Some users of that function will update them after calling it, but most don't. As we are passed the clk_core pointer, we have access to those boundaries in clk_core_init_rate_req() however, so let's just fill it there and remove it from the few callers that do it right. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-18-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Introduce clk_hw_init_rate_request()Maxime Ripard3-10/+36
clk-divider instantiates clk_rate_request internally for its round_rate implementations to share the code with its determine_rate implementations. However, it's missing a few fields (min_rate, max_rate) that would be initialized properly if it was using clk_core_init_rate_req(). Let's create the clk_hw_init_rate_request() function for clock providers to be able to share the code to instation clk_rate_requests with the framework. This will also be useful for some tests introduced in later patches. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-17-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock() to its callerMaxime Ripard1-5/+3
The clk_rate_request structure is used internally as an argument for the clk_core_determine_round_nolock() and clk_core_round_rate_nolock(). In both cases, the clk_core_init_rate_req() function is used to initialize the clk_rate_request structure. However, the expectation on who gets to call that function is inconsistent between those two functions. Indeed, clk_core_determine_round_nolock() will assume the structure is properly initialized and will just use it. On the other hand, clk_core_round_rate_nolock() will call clk_core_init_rate_req() itself, expecting the caller to have filled only a minimal set of parameters (rate, min_rate and max_rate). If we ignore the calling convention inconsistency, this leads to a second inconsistency for drivers: * If they get called by the framework through clk_core_round_rate_nolock(), the rate, min_rate and max_rate fields will be filled by the caller, and the best_parent_rate and best_parent_hw fields will get filled by clk_core_init_rate_req(). * If they get called by a driver through __clk_determine_rate (and thus clk_core_round_rate_nolock), only best_parent_rate and best_parent_hw are being explicitly set by the framework. Even though we can reasonably expect rate to be set, only one of the 6 in-tree users explicitly set min_rate and max_rate. * If they get called by the framework through clk_core_determine_round_nolock(), then we have two callpaths. Either it will be called by clk_core_round_rate_nolock() itself, or it will be called by clk_calc_new_rates(), which will properly initialize rate, min_rate, max_rate itself, and best_parent_rate and best_parent_hw through clk_core_init_rate_req(). Even though the first and third case seems equivalent, they aren't when the clock has CLK_SET_RATE_PARENT. Indeed, in such a case clk_core_round_rate_nolock() will call itself on the current parent clock with the same clk_rate_request structure. The clk_core_init_rate_req() function will then be called on the parent clock, with the child clk_rate_request pointer and will fill the best_parent_rate and best_parent_hw fields with the parent context. When the whole recursion stops and the call returns, the initial caller will end up with a clk_rate_request structure with some information of the child clock (rate, min_rate, max_rate) and some others of the last clock up the tree whose child had CLK_SET_RATE_PARENT (best_parent_hw, best_parent_rate). In the most common case, best_parent_rate is going to be equal on all the parent clocks so it's not a big deal. However, best_parent_hw is going to point to a clock that never has been a valid parent for that clock which is definitely confusing. In order to fix the calling inconsistency, let's move the clk_core_init_rate_req() calls to the callers, which will also help a bit with the clk_core_round_rate_nolock() recursion. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-16-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Change clk_core_init_rate_req prototypeMaxime Ripard1-4/+6
The expectation is that a clk_rate_request structure is supposed to be initialized using clk_core_init_rate_req(), yet the rate we want to request still needs to be set by hand. Let's just pass the rate as a function argument so that callers don't have any extra work to do. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-15-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Set req_rate on reparentingMaxime Ripard2-0/+261
If a non-rate clock started by default with a parent that never registered, core->req_rate will be 0. The expectation is that whenever the parent will be registered, req_rate will be updated with the new value that has just been computed. However, if that clock is a mux, clk_set_parent() can also make that clock no longer orphan. In this case however, we never update req_rate. The natural solution to this would be to update core->rate and core->req_rate in clk_reparent() by calling clk_recalc(). However, this doesn't work in all cases. Indeed, clk_recalc() is called by __clk_set_parent_before(), __clk_set_parent() and clk_core_reparent(). Both __clk_set_parent_before() and __clk_set_parent will call clk_recalc() with the enable_lock taken through a call to clk_enable_lock(), the underlying locking primitive being a spinlock. clk_recalc() calls the backing driver .recalc_rate hook, and that implementation might sleep if the underlying device uses a bus with accesses that might sleep, such as i2c. In such a situation, we would end up sleeping while holding a spinlock, and thus in an atomic section. In order to work around this, we can move the core->rate and core->req_rate update to the clk_recalc() calling sites, after the enable_lock has been released if it was taken. The only situation that could still be problematic is the clk_core_reparent() -> clk_reparent() case that doesn't have any locking. clk_core_reparent() is itself called by clk_hw_reparent(), which is then called by 4 drivers: * clk-stm32mp1.c, stm32/clk-stm32-core.c and tegra/clk-tegra210-emc.c use it in their set_parent implementation. The set_parent hook is only called by __clk_set_parent() and clk_change_rate(), both of them calling it without the enable_lock taken. * clk/tegra/clk-tegra124-emc.c calls it as part of its set_rate implementation. set_rate is only called by clk_change_rate(), again without the enable_lock taken. In both cases we can't end up in a situation where the clk_hw_reparent() caller would hold a spinlock, so it seems like this is a good workaround. Let's also add some unit tests to make sure we cover the original bug. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-14-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Take into account uncached clocks in clk_set_rate_range()Maxime Ripard2-1/+36
clk_set_rate_range() will use the last requested rate for the clock when it calls into the driver set_rate hook. However, if CLK_GET_RATE_NOCACHE is set on that clock, the last requested rate might not be matching the current rate of the clock. In such a case, let's read out the rate from the hardware and use that in our set_rate instead. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-13-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: tests: Add some tests for orphan with multiple parentsMaxime Ripard1-0/+237
Let's leverage the dummy mux with multiple parents we have to create a mux whose default parent will never be registered, and thus will always be orphan by default. We can then create some tests to make sure that the clock API behaves properly in such a case, and that the transition to a non-orphan clock when we change the parent is done properly. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-12-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: tests: Add tests for mux with multiple parentsMaxime Ripard1-0/+121
We'll need to test a few corner cases that occur when we have a mux clock whose default parent is missing. For now, let's create the context structure and the trivial ops, along with a test suite that just tests trivial things for now, without considering the orphan case. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-11-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: tests: Add tests for single parent muxMaxime Ripard1-9/+185
We have a few tests for a mux with a single parent, testing the case where it used to be orphan. Let's leverage most of the code but register the clock properly to test a few trivial things. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-10-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: tests: Add tests for uncached clockMaxime Ripard1-1/+92
The clock framework supports clocks that can have their rate changed without the kernel knowing about it using the CLK_GET_RATE_NOCACHE flag. As its name suggests, this flag turns off the rate caching in the clock framework, reading out the rate from the hardware any time we need to read it. Let's add a couple of tests to make sure it works as intended. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-9-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: tests: Add reference to the orphan mux bug reportMaxime Ripard1-0/+3
Some more context might be useful for unit-tests covering a previously reported bug, so let's add a link to the discussion for that bug. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-8-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: tests: Add test suites descriptionMaxime Ripard1-0/+33
We start to have a few test suites, and we'll add more, so it will get pretty confusing to figure out what is supposed to be tested in what suite. Let's add some comments to explain what setup they create, and what we should be testing in every suite. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-7-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Clarify clk_get_rate() expectationsMaxime Ripard1-2/+3
As shown by a number of clock users already, clk_get_rate() can be called whether or not the clock is enabled. Similarly, a number of clock drivers will return a rate of 0 whenever the rate cannot be figured out. Since it was a bit ambiguous before, let's make it clear in the clk_get_rate() documentation. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-6-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Mention that .recalc_rate can return 0 on errorMaxime Ripard1-2/+3
Multiple platforms (amlogic, imx8) return 0 when the clock rate cannot be determined properly by the recalc_rate hook. Mention in the documentation that the framework is ok with that. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-5-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Skip clamping when rounding if there's no boundariesMaxime Ripard1-1/+13
Commit 948fb0969eae ("clk: Always clamp the rounded rate") recently started to clamp the request rate in the clk_rate_request passed as an argument of clk_core_determine_round_nolock() with the min_rate and max_rate fields of that same request. While the clk_rate_requests created by the framework itself always have those fields set, some drivers will create it themselves and don't always fill min_rate and max_rate. In such a case, we end up clamping the rate with a minimum and maximum of 0, thus always rounding the rate to 0. Let's skip the clamping if both min_rate and max_rate are set to 0 and complain so that it gets fixed. Fixes: 948fb0969eae ("clk: Always clamp the rounded rate") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-4-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Drop the rate range on clk_put()Maxime Ripard2-14/+141
When clk_put() is called we don't make another clk_set_rate() call to re-evaluate the rate boundaries. This is unlike clk_set_rate_range() that evaluates the rate again each time it is called. However, clk_put() is essentially equivalent to clk_set_rate_range() since after clk_put() completes the consumer's boundaries shouldn't be enforced anymore. Let's add a call to clk_set_rate_range() in clk_put() to make sure those rate boundaries are dropped and the clock provider drivers can react. In order to be as non-intrusive as possible, we'll just make that call if the clock had non-default boundaries. Also add a few tests to make sure this case is covered. Fixes: c80ac50cbb37 ("clk: Always set the rate on clk_set_range_rate") Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-3-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: test: Switch to clk_hw_get_clkMaxime Ripard1-19/+55
Following the clk_hw->clk pointer is equivalent to calling clk_hw_get_clk(), but will make the job harder if we need to rework that part in the future. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-2-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15arm64: dts: mediatek: mt6795: Add CPUX system timer nodeAngeloGioacchino Del Regno1-0/+8
Add a node for mt6795-systimer: this is necessary to start the System Timer(s) for all cores, finally making CNTVCT_EL0 usable. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220729093536.27623-1-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2022-09-15soc: mediatek: mutex: Add support for MT6795 Helio X10 display mutexAngeloGioacchino Del Regno1-0/+16
MT6795 has the same mutex mod/sof register layout as MT2712 and MT8173, but supports only four SOF, as it has two DSI and one DPI. Support is added by reusing most of the MT8173 data, with the addition of a mt6795-specific SOF array (and devicetree compatible, of course). Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220913140121.403637-3-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2022-09-15dt-bindings: soc: mediatek: Add display mutex support for MT6795AngeloGioacchino Del Regno1-0/+1
Add compatible for MT6795 Helio X10 SoC. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220913140121.403637-2-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2022-09-15ALSA: hda/realtek: Add quirk for ASUS GA503R laptopLuke D. Jones1-0/+1
The ASUS G15 2022 (GA503R) series laptop has the same node-to-DAC pairs as early models and the G14, this includes bass speakers which are by default mapped incorrectly to the 0x06 node. Add a quirk to use the same DAC pairs as the G14. Signed-off-by: Luke D. Jones <luke@ljones.dev> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220915080921.35563-4-luke@ljones.dev Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-15ALSA: hda/realtek: Add pincfg for ASUS G533Z HP jackLuke D. Jones1-0/+11
Fixes up the pincfg for ASUS ROG Strix G15 (G533Z) headphone combo jack [ Fixed the position in the quirk table by tiwai ] Signed-off-by: Luke D. Jones <luke@ljones.dev> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220915080921.35563-3-luke@ljones.dev Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-15ALSA: hda/realtek: Add pincfg for ASUS G513 HP jackLuke D. Jones1-0/+11
Fixes up the pincfg for ASUS ROG Strix G513 headphone and mic combo jack [ Fixed the position in the quirk table by tiwai ] Signed-off-by: Luke D. Jones <luke@ljones.dev> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220915080921.35563-2-luke@ljones.dev Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-15ALSA: hda/realtek: Re-arrange quirk table entriesTakashi Iwai1-3/+3
A few entries have been mistakenly inserted in wrong positions without considering the SSID ordering. Place them at right positions. Fixes: b7557267c233 ("ALSA: hda/realtek: Add quirk for ASUS GA402") Fixes: 94db9cc8f8fa ("ALSA: hda/realtek: Add quirk for ASUS GU603") Fixes: 739d0959fbed ("ALSA: hda: Add quirk for ASUS Flow x13") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220915154724.31634-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-15ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5530 laptopCallum Osmotherly1-0/+1
Just as with the 5570 (and the other Dell laptops), this enables the two subwoofer speakers on the Dell Precision 5530 together with the main ones, significantly increasing the audio quality. I've tested this myself on a 5530 and can confirm it's working as expected. Signed-off-by: Callum Osmotherly <callum.osmotherly@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/YyMjQO3mhyXlMbCf@piranha Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-15arm64: dts: qcom: ipq8074: fix PCIe PHY serdes sizeJohan Hovold1-2/+2
The size of the PCIe PHY serdes register region is 0x1c4 and the corresponding 'reg' property should specifically not include the adjacent regions that are defined in the child node (e.g. tx and rx). Fixes: 33057e1672fe ("ARM: dts: ipq8074: Add pcie nodes") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220915143431.19842-1-johan+linaro@kernel.org
2022-09-15Merge tag 'imx-fixes-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixesArnd Bergmann9-18/+31
i.MX fixes for 6.0, 2nd round: - A couple of TQMa8MPQL device tree fixes from Alexander Stein on button GPIOs and PCF85063 RTC alarm pinctrl. - Include phy-imx8-pcie.h header in tqma8mqml-mba8mx device tree to fix build errors when this SoM dtsi is included on customer carrier boards. - Remove GPU power domain reset from i.MX8MN device tree to fix a sporadical hang seen with GPUMIX powering up. - Correct CPLD_Dn GPIO label mapping for Toradex Verdin based Menlo board. - Add ARCH_NXP back to defconfig, which was dropped accidentally by commit 566e373fe047 ("arm64: Kconfig.platforms: Group NXP platforms together"). - Add missing #reset-cells for i.MX8ULP PCC clock controllers. - Update PMIC voltages for imx8mm-verdin board to fix an issue with one Toradex SKU that uses a consumer-grade chip that is capable of going up to 1.8GHz at 1.00V. - A series of imx8mp-venice-gw74xx device tree changes from Tim Harvey to fix things on CAN STBY polarity, KSZ9477 CPU uplink port and phy-mode. * tag 'imx-fixes-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: arm64: dts: imx8mp-venice-gw74xx: fix port/phy validation arm64: dts: imx8mp-venice-gw74xx: fix ksz9477 cpu port arm64: dts: imx8mp-venice-gw74xx: fix CAN STBY polarity arm64: dts: tqma8mqml: Include phy-imx8-pcie.h header arm64: defconfig: enable ARCH_NXP arm64: dts: imx8mp-tqma8mpql-mba8mpxl: add missing pinctrl for RTC alarm arm64: dts: imx8mm-verdin: extend pmic voltages arm64: dts: imx8ulp: add #reset-cells for pcc arm64: dts: tqma8mpxl-ba8mpxl: Fix button GPIOs arm64: dts: imx8mn: remove GPU power domain reset arm64: dts: imx8mm: Reverse CPLD_Dn GPIO label mapping on MX8Menlo Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-15locking: Add __sched to semaphore functionsNamhyung Kim1-6/+6
The internal functions are marked with __sched already, let's do the same for external functions too so that we can skip them in the stack trace. Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20220909000803.4181857-1-namhyung@kernel.org
2022-09-15locking/rwsem: Disable preemption while trying for rwsem lockGokul krishna Krishnakumar1-2/+12
Make the region inside the rwsem_write_trylock non preemptible. We observe RT task is hogging CPU when trying to acquire rwsem lock which was acquired by a kworker task but before the rwsem owner was set. Here is the scenario: 1. CFS task (affined to a particular CPU) takes rwsem lock. 2. CFS task gets preempted by a RT task before setting owner. 3. RT task (FIFO) is trying to acquire the lock, but spinning until RT throttling happens for the lock as the lock was taken by CFS task. This patch attempts to fix the above issue by disabling preemption until owner is set for the lock. While at it also fix the issues at the places where rwsem_{set,clear}_owner() are called. This also adds lockdep annotation of preemption disable in rwsem_{set,clear}_owner() on Peter Z. suggestion. Signed-off-by: Gokul krishna Krishnakumar <quic_gokukris@quicinc.com> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Waiman Long <longman@redhat.com> Link: https://lore.kernel.org/r/1662661467-24203-1-git-send-email-quic_mojha@quicinc.com
2022-09-15locking: Detect includes rwlock.h outside of spinlock.hSebastian Andrzej Siewior6-5/+7
From: Michael S. Tsirkin <mst@redhat.com> The check for __LINUX_SPINLOCK_H within rwlock.h (and other files) detects the direct include of the header file if it is at the very beginning of the include section. If it is listed later then chances are high that spinlock.h was already included (including rwlock.h) and the additional listing of rwlock.h will not cause any failure. On PREEMPT_RT this additional rwlock.h will lead to compile failures since it uses a different rwlock implementation. Add __LINUX_INSIDE_SPINLOCK_H to spinlock.h and check for this instead of __LINUX_SPINLOCK_H to detect wrong includes. This will help detect direct includes of rwlock.h with without PREEMPT_RT enabled. [ bigeasy: add remaining __LINUX_SPINLOCK_H user and rewrite commit description. ] Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/YweemHxJx7O8rjBx@linutronix.de
2022-09-15objtool,x86: Teach decode about LOOP* instructionsPeter Zijlstra1-0/+6
When 'discussing' control flow Masami mentioned the LOOP* instructions and I realized objtool doesn't decode them properly. As it turns out, these instructions are somewhat inefficient and as such unlikely to be emitted by the compiler (a few vmlinux.o checks can't find a single one) so this isn't critical, but still, best to decode them properly. Reported-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/Yxhd4EMKyoFoH9y4@hirez.programming.kicks-ass.net
2022-09-15x86,retpoline: Be sure to emit INT3 after JMP *%\regPeter Zijlstra2-1/+12
Both AMD and Intel recommend using INT3 after an indirect JMP. Make sure to emit one when rewriting the retpoline JMP irrespective of compiler SLS options or even CONFIG_SLS. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Link: https://lkml.kernel.org/r/Yxm+QkFPOhrVSH6q@hirez.programming.kicks-ass.net
2022-09-15sched/fair: Move call to list_last_entry() in detach_tasksVincent Guittot1-2/+2
Move the call to list_last_entry() in detach_tasks() after testing loop_max and loop_break. Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20220825122726.20819-4-vincent.guittot@linaro.org
2022-09-15sched/fair: Cleanup loop_max and loop_breakVincent Guittot3-12/+11
sched_nr_migrate_break is set to a fix value and never changes so we can replace it by a define SCHED_NR_MIGRATE_BREAK. Also, we adjust SCHED_NR_MIGRATE_BREAK to be aligned with the init value of sysctl_sched_nr_migrate which can be init to different values. Then, use SCHED_NR_MIGRATE_BREAK to init sysctl_sched_nr_migrate. The behavior stays unchanged unless you modify sysctl_sched_nr_migrate trough debugfs. Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20220825122726.20819-3-vincent.guittot@linaro.org
2022-09-15sched/fair: Make sure to try to detach at least one movable taskVincent Guittot1-3/+9
During load balance, we try at most env->loop_max time to move a task. But it can happen that the loop_max LRU tasks (ie tail of the cfs_tasks list) can't be moved to dst_cpu because of affinity. In this case, loop in the list until we found at least one. The maximum of detached tasks remained the same as before. Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20220825122726.20819-2-vincent.guittot@linaro.org
2022-09-15ARM: footbridge: remove custom DMA address handlingArnd Bergmann10-42/+32
Footbridge is the last Arm platform that has its own __virt_to_bus()/__bus_to_virt()/phys_to_dma()/dma_to_phys() abstraction, but this is just a simple offset now. For PCI devices, the offset that is programmed into the PCI bridge must also be set in each device using dma_direct_set_offset(). As Arm does not have a pcibios_bus_add_device() helper yet, just use a bus notifier for this. For the ISA DMA, drivers now pass a non-translated physical address into set_dma_addr(), so they have to be converted back with the corresponding isa_bus_to_virt() function and then into the correct bus address with the offset using the isa_dma_dev. Tested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-15arm64: defconfig: Make TEGRA186_GPC_DMA built-inAkhil R1-1/+1
Make TEGRA186_GPC_DMA driver as built-in since the clients using the DMA (like I2C_TEGRA etc) are built-in. This would avoid the potential long delay probe deferral can cause. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: dts: rockchip: Add HDMI supplies on rk3399-roc-pcMarkus Reichl1-2/+4
Add avdd-0v9-supply and avdd-1v8-supply to hdmi node for rk3399-roc-pc to silence dmesg warning and match the name of the 1v8 supply to the circuit sheet. Signed-off-by: Markus Reichl <m.reichl@fivetechno.de> Link: https://lore.kernel.org/r/20220915111138.1108-1-m.reichl@fivetechno.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-15arm64: dts: rockchip: Support gru-scarlet sku{2,4} variantsBrian Norris1-1/+13
The Gru-Scarlet family includes a variety of SKU identifiers, using parts of a 3-bit space {0..7}. SKU2 and SKU4 devices (under a few different manufacturer names) also use the Innolux display. Without this, a SKU2 device may non-deterministically (depending on the matching order of DTBs and bootloader behavior) select either one of the INX DTBs (rk3399-gru-scarlet-dumo.dtb or rk3399-gru-scarlet-inx.dtb) or the KingDisplay DTB (rk3399-gru-scarlet-kd.dtb), to ill effect. For reference, the original vendor tree source: CHROMIUM: arm64: dts: rockchip: add sku{0,2,4} compatibility https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f6ed665c9e2eb37fb2680debbb36ec9fb0e8fb97 CHROMIUM: arm64: dts: rockchip: scarlet: add SKU0 device tree https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9987c8776f4b087d135d761e59f7fa6cc83fc7fc Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20220817123350.2.I5f4fd0808a927b08e267c189712fb4a85931fd3b@changeid Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.