Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
454a8f59 |
| 14-Jul-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: rockchip: Consistently name pwm_chip variables "chip"
Most variables holding a pointer to a pwm_chip are called "chip" which is also the usual name in most other PWM drivers. Rename the single
pwm: rockchip: Consistently name pwm_chip variables "chip"
Most variables holding a pointer to a pwm_chip are called "chip" which is also the usual name in most other PWM drivers. Rename the single variable that have a different name to be called "chip", too, for consistency.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16 |
|
#
18a95d36 |
| 03-Mar-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: rockchip: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error
pwm: rockchip: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert this driver from always returning zero in the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12 |
|
#
790a8bae |
| 02-Dec-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: rockchip: Propagate errors in .get_state() to the caller
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses.
Reviewed-by: Heiko Stuebner <heiko@
pwm: rockchip: Propagate errors in .get_state() to the caller
.get_state() can return an error indication. Make use of it to propagate failing hardware accesses.
Reviewed-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-10-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
6c452cff |
| 02-Dec-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: Make .get_state() callback return an error code
.get_state() might fail in some cases. To make it possible that a driver signals such a failure change the prototype of .get_state() to return an
pwm: Make .get_state() callback return an error code
.get_state() might fail in some cases. To make it possible that a driver signals such a failure change the prototype of .get_state() to return an error code.
This patch was created using coccinelle and the following semantic patch:
@p1@ identifier getstatefunc; identifier driver; @@ struct pwm_ops driver = { ..., .get_state = getstatefunc ,... };
@p2@ identifier p1.getstatefunc; identifier chip, pwm, state; @@ -void +int getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state) { ... - return; + return 0; ... }
plus the actual change of the prototype in include/linux/pwm.h (plus some manual fixing of indentions and empty lines).
So for now all drivers return success unconditionally. They are adapted in the following patches to make the changes easier reviewable.
Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Acked-by: Douglas Anderson <dianders@chromium.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63 |
|
#
4b8857c3 |
| 22-Aug-2022 |
zhaoxiao <zhaoxiao@uniontech.com> |
pwm: rockchip: Convert to use dev_err_probe()
It's fine to call dev_err_probe() in ->probe() when error code is known. Convert the driver to use dev_err_probe().
Signed-off-by: zhaoxiao <zhaoxiao@u
pwm: rockchip: Convert to use dev_err_probe()
It's fine to call dev_err_probe() in ->probe() when error code is known. Convert the driver to use dev_err_probe().
Signed-off-by: zhaoxiao <zhaoxiao@uniontech.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49 |
|
#
84ea61f6 |
| 07-Jul-2021 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: rockchip: Unprepare clocks only after the PWM was unregistered
The driver is supposed to stay functional until pwmchip_remove() returns. So disable clocks only after that.
pwmchip_remove() alw
pwm: rockchip: Unprepare clocks only after the PWM was unregistered
The driver is supposed to stay functional until pwmchip_remove() returns. So disable clocks only after that.
pwmchip_remove() always returns 0, so the return code can be ignored which keeps rockchip_pwm_remove() a bit simpler and allows to eventually make pwmchip_remove() return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
9d768cd7 |
| 07-Jul-2021 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: rockchip: Don't modify HW state in .remove() callback
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer need
pwm: rockchip: Don't modify HW state in .remove() callback
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36 |
|
#
e9fdf122 |
| 10-May-2021 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: Simplify all drivers with explicit of_pwm_n_cells = 3
With the previous commit there is no need for the lowlevel driver any more to specify it it uses two or three cells. So simplify accordingl
pwm: Simplify all drivers with explicit of_pwm_n_cells = 3
With the previous commit there is no need for the lowlevel driver any more to specify it it uses two or three cells. So simplify accordingly.
The only non-trival change affects the pwm-rockchip driver: It used to only support three cells if the hardware supports polarity. Now the default number depends on the device tree which has to match hardware anyhow (and if it doesn't the error is just a bit delayed as a PWM handle with an inverted setting is catched when pwm_apply_state() is called).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20 |
|
#
f9a8ee8c |
| 01-Mar-2021 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: Always allocate PWM chip base ID dynamically
Since commit 5e5da1e9fbee ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") all drivers use dynamic ID allocation explicitly. New drive
pwm: Always allocate PWM chip base ID dynamically
Since commit 5e5da1e9fbee ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") all drivers use dynamic ID allocation explicitly. New drivers are supposed to do the same, so remove support for driver specified base IDs and drop all assignments in the low-level drivers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
11be938a |
| 19-Jan-2021 |
Simon South <simon@simonsouth.net> |
pwm: rockchip: Enable clock before calling clk_get_rate()
The documentation for clk_get_rate() in include/linux/clk.h states the function's result is valid only for a clock source that has been enab
pwm: rockchip: Enable clock before calling clk_get_rate()
The documentation for clk_get_rate() in include/linux/clk.h states the function's result is valid only for a clock source that has been enabled. However, the Rockchip PWM driver uses this function in two places to query the rate of a clock without first ensuring it is enabled.
Fix this by modifying rockchip_pwm_get_state() and rockchip_pwm_apply() so they enable a device's PWM clock before querying its rate (in the latter case, the querying is actually done in rockchip_pwm_config()) and disable the clock again before returning.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Simon South <simon@simonsouth.net> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
d21ba5d6 |
| 19-Jan-2021 |
Simon South <simon@simonsouth.net> |
pwm: rockchip: Eliminate potential race condition when probing
Commit 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") introduced a potential race condition in rockchip_pwm_pro
pwm: rockchip: Eliminate potential race condition when probing
Commit 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") introduced a potential race condition in rockchip_pwm_probe(): A consumer could enable an inactive PWM, or disable a running one, between rockchip_pwm_probe() registering the device via pwmchip_add() and checking whether it is enabled (to determine whether it was started by a bootloader). This could result in a device's PWM clock being either enabled once more than necessary, potentially causing it to continue running when no longer needed, or disabled once more than necessary, producing a warning from the kernel.
Eliminate these possibilities by modifying rockchip_pwm_probe() so it checks whether a device is enabled before registering it rather than after.
Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Reported-by: Trent Piepho <tpiepho@gmail.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
c9f809d0 |
| 19-Jan-2021 |
Simon South <simon@simonsouth.net> |
pwm: rockchip: Replace "bus clk" with "PWM clk"
Clarify the Rockchip PWM driver's error messages by referring to the clock that operates a PWM device as the "PWM" clock, matching its name in the dev
pwm: rockchip: Replace "bus clk" with "PWM clk"
Clarify the Rockchip PWM driver's error messages by referring to the clock that operates a PWM device as the "PWM" clock, matching its name in the device tree, rather than the "bus" clock (which is especially misleading in the case of devices that also use a separate clock for bus access).
Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
d5d8d675 |
| 19-Jan-2021 |
Simon South <simon@simonsouth.net> |
pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare()
If rockchip_pwm_probe() fails to register a PWM device it calls clk_unprepare() for the device's PWM clock, without having fir
pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare()
If rockchip_pwm_probe() fails to register a PWM device it calls clk_unprepare() for the device's PWM clock, without having first disabled the clock and before jumping to an error handler that also unprepares it. This is likely to produce warnings from the kernel about the clock being unprepared when it is still enabled, and then being unprepared when it has already been unprepared.
Prevent these warnings by removing this unnecessary call to clk_unprepare().
Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
d9b657a5 |
| 19-Jan-2021 |
Simon South <simon@simonsouth.net> |
pwm: rockchip: Enable APB clock during register access while probing
Commit 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") modified rockchip_pwm_probe() to access a PWM devi
pwm: rockchip: Enable APB clock during register access while probing
Commit 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") modified rockchip_pwm_probe() to access a PWM device's registers directly to check whether or not the device is enabled, but did not also change the function so it first enables the device's APB clock to be certain the device can respond. This risks hanging the kernel on systems with PWM devices that use more than a single clock.
Avoid this by enabling the device's APB clock before accessing its registers (and disabling the clock when register access is complete).
Fixes: 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") Reported-by: Thierry Reding <thierry.reding@gmail.com> Suggested-by: Trent Piepho <tpiepho@gmail.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7 |
|
#
5119ee9e |
| 29-Dec-2019 |
Yangtao Li <tiny.windzz@gmail.com> |
pwm: rockchip: Convert to devm_platform_ioremap_resource()
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Reviewed-by: Heiko Stuebner <heik
pwm: rockchip: Convert to devm_platform_ioremap_resource()
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
58516ac4 |
| 19-Jan-2021 |
Simon South <simon@simonsouth.net> |
pwm: rockchip: Eliminate potential race condition when probing
[ Upstream commit d21ba5d6217bd5a6a696678385906ed1994b380b ]
Commit 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PW
pwm: rockchip: Eliminate potential race condition when probing
[ Upstream commit d21ba5d6217bd5a6a696678385906ed1994b380b ]
Commit 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") introduced a potential race condition in rockchip_pwm_probe(): A consumer could enable an inactive PWM, or disable a running one, between rockchip_pwm_probe() registering the device via pwmchip_add() and checking whether it is enabled (to determine whether it was started by a bootloader). This could result in a device's PWM clock being either enabled once more than necessary, potentially causing it to continue running when no longer needed, or disabled once more than necessary, producing a warning from the kernel.
Eliminate these possibilities by modifying rockchip_pwm_probe() so it checks whether a device is enabled before registering it rather than after.
Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Reported-by: Trent Piepho <tpiepho@gmail.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
6f503e4e |
| 19-Jan-2021 |
Simon South <simon@simonsouth.net> |
pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare()
[ Upstream commit d5d8d675865ccddfe4da26c85f22c55cec663bf2 ]
If rockchip_pwm_probe() fails to register a PWM device it calls
pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare()
[ Upstream commit d5d8d675865ccddfe4da26c85f22c55cec663bf2 ]
If rockchip_pwm_probe() fails to register a PWM device it calls clk_unprepare() for the device's PWM clock, without having first disabled the clock and before jumping to an error handler that also unprepares it. This is likely to produce warnings from the kernel about the clock being unprepared when it is still enabled, and then being unprepared when it has already been unprepared.
Prevent these warnings by removing this unnecessary call to clk_unprepare().
Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
39ab0927 |
| 19-Jan-2021 |
Simon South <simon@simonsouth.net> |
pwm: rockchip: Enable APB clock during register access while probing
[ Upstream commit d9b657a5cdbd960de35dee7e06473caf44a9016f ]
Commit 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running whil
pwm: rockchip: Enable APB clock during register access while probing
[ Upstream commit d9b657a5cdbd960de35dee7e06473caf44a9016f ]
Commit 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") modified rockchip_pwm_probe() to access a PWM device's registers directly to check whether or not the device is enabled, but did not also change the function so it first enables the device's APB clock to be certain the device can respond. This risks hanging the kernel on systems with PWM devices that use more than a single clock.
Avoid this by enabling the device's APB clock before accessing its registers (and disabling the clock when register access is complete).
Fixes: 457f74abbed0 ("pwm: rockchip: Keep enabled PWMs running while probing") Reported-by: Thierry Reding <thierry.reding@gmail.com> Suggested-by: Trent Piepho <tpiepho@gmail.com> Signed-off-by: Simon South <simon@simonsouth.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
836719f8 |
| 26-Aug-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
pwm: rockchip: Simplify with dev_err_probe()
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzyszto
pwm: rockchip: Simplify with dev_err_probe()
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
457f74ab |
| 19-Sep-2020 |
Simon South <simon@simonsouth.net> |
pwm: rockchip: Keep enabled PWMs running while probing
Following commit cfc4c189bc70 ("pwm: Read initial hardware state at request time") the Rockchip PWM driver can no longer assume a device's pwm_
pwm: rockchip: Keep enabled PWMs running while probing
Following commit cfc4c189bc70 ("pwm: Read initial hardware state at request time") the Rockchip PWM driver can no longer assume a device's pwm_state structure has been populated after a call to pwmchip_add(). Consequently, the test in rockchip_pwm_probe() intended to prevent the driver from stopping PWM devices already enabled by the bootloader no longer functions reliably and this can lead to the kernel hanging during startup, particularly on devices like the Pinebook Pro that use a PWM-controlled backlight for their display.
Avoid this by querying the device directly at probe time to determine whether or not it is enabled.
Fixes: cfc4c189bc70 ("pwm: Read initial hardware state at request time") Signed-off-by: Simon South <simon@simonsouth.net> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1 |
|
#
cad0f296 |
| 19-Sep-2019 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
pwm: rockchip: Simplify rockchip_pwm_get_state()
The way state->enabled is computed is rather convoluted and hard to read - both branches of the if() actually do the exact same thing. So remove the
pwm: rockchip: Simplify rockchip_pwm_get_state()
The way state->enabled is computed is rather convoluted and hard to read - both branches of the if() actually do the exact same thing. So remove the if(), and further simplify "<boolean condition> ? true : false" to "<boolean condition>".
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
71523d18 |
| 24-Aug-2019 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: Ensure pwm_apply_state() doesn't modify the state argument
It is surprising for a PWM consumer when the variable holding the requested state is modified by pwm_apply_state(). Consider for examp
pwm: Ensure pwm_apply_state() doesn't modify the state argument
It is surprising for a PWM consumer when the variable holding the requested state is modified by pwm_apply_state(). Consider for example a driver doing:
#define PERIOD 5000000 #define DUTY_LITTLE 10 ... struct pwm_state state = { .period = PERIOD, .duty_cycle = DUTY_LITTLE, .polarity = PWM_POLARITY_NORMAL, .enabled = true, };
pwm_apply_state(mypwm, &state); ... state.duty_cycle = PERIOD / 2; pwm_apply_state(mypwm, &state);
For sure the second call to pwm_apply_state() should still have state.period = PERIOD and not something the hardware driver chose for a reason that doesn't necessarily apply to the second call.
So declare the state argument as a pointer to a const type and adapt all drivers' .apply callbacks.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
797a5ebc |
| 24-Aug-2019 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: rockchip: Don't update the state for the caller of pwm_apply_state()
The pwm-rockchip driver is one of only three PWM drivers which updates the state for the caller of pwm_apply_state(). This m
pwm: rockchip: Don't update the state for the caller of pwm_apply_state()
The pwm-rockchip driver is one of only three PWM drivers which updates the state for the caller of pwm_apply_state(). This might have surprising results if the caller reuses the values expecting them to still represent the same state.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
ba73deb1 |
| 02-Sep-2019 |
Uwe Kleine-König <uwe@kleine-koenig.org> |
pwm: rockchip: Set polarity unconditionally in .get_state()
Don't rely on *state being zero initialized and PWM_POLARITY_NORMAL being zero. So always assign .polarity.
Signed-off-by: Uwe Kleine-Kön
pwm: rockchip: Set polarity unconditionally in .get_state()
Don't rely on *state being zero initialized and PWM_POLARITY_NORMAL being zero. So always assign .polarity.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8 |
|
#
d2912cb1 |
| 04-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|