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, 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 |
|
#
bbacca0e |
| 03-Mar-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: bcm-iproc: 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 erro
pwm: bcm-iproc: 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 |
|
#
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, 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 |
|
#
2aec85b2 |
| 07-Jun-2022 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_30.RULE (part 2)
Based on the normalized pattern:
this program is free software you can redistribute it and/or modify it un
treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_30.RULE (part 2)
Based on the normalized pattern:
this program is free software you can redistribute it and/or modify it under the terms of the gnu general public license as published by the free software foundation version 2 this program is distributed as is without any warranty of any kind whether express or implied without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference.
Reviewed-by: Allison Randal <allison@lohutok.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: 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, 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 |
|
#
d4ac3917 |
| 24-Mar-2021 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: bcm-iproc: Free resources only after pwmchip_remove()
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clock.
Signed-off-by: Uwe
pwm: bcm-iproc: Free resources only after pwmchip_remove()
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clock.
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.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, 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 |
|
#
ed98401f |
| 29-Dec-2019 |
Yangtao Li <tiny.windzz@gmail.com> |
pwm: bcm-iproc: 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: Uwe Kleine-König <u
pwm: bcm-iproc: 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
6ced5ff0 |
| 17-Jul-2020 |
Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> |
pwm: bcm-iproc: handle clk_get_rate() return
Handle clk_get_rate() returning 0 to avoid possible division by zero.
Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-
pwm: bcm-iproc: handle clk_get_rate() return
Handle clk_get_rate() returning 0 to avoid possible division by zero.
Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
9443f2c8 |
| 29-Jun-2020 |
Lee Jones <lee.jones@linaro.org> |
pwm: bcm-iproc: Remove impossible comparison when validating duty cycle
'duty' here is an unsigned int, thus checking for <0 will always evaluate to false.
Fixes the following W=1 warning:
driver
pwm: bcm-iproc: Remove impossible comparison when validating duty cycle
'duty' here is an unsigned int, thus checking for <0 will always evaluate to false.
Fixes the following W=1 warning:
drivers/pwm/pwm-bcm-iproc.c:147:12: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-pwm@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> 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 |
|
#
24906a41 |
| 17-Oct-2019 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: bcm-iproc: Prevent unloading the driver module while in use
The owner member of struct pwm_ops must be set to THIS_MODULE to increase the reference count of the module such that the module cann
pwm: bcm-iproc: Prevent unloading the driver module while in use
The owner member of struct pwm_ops must be set to THIS_MODULE to increase the reference count of the module such that the module cannot be removed while its code is in use.
Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, 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 ...
|
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, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4 |
|
#
daa5abc4 |
| 05-Jul-2016 |
Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> |
pwm: Add support for Broadcom iProc PWM controller
Add support for the PWM controller present in Broadcom's iProc family of SoCs. It has been tested on the Northstar+ bcm958625HR board.
Signed-off
pwm: Add support for Broadcom iProc PWM controller
Add support for the PWM controller present in Broadcom's iProc family of SoCs. It has been tested on the Northstar+ bcm958625HR board.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> [thierry.reding@gmail.com: bunch of coding style fixes, cleanups] Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
6ced5ff0 |
| 17-Jul-2020 |
Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> |
pwm: bcm-iproc: handle clk_get_rate() return Handle clk_get_rate() returning 0 to avoid possible division by zero. Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM cont
pwm: bcm-iproc: handle clk_get_rate() return Handle clk_get_rate() returning 0 to avoid possible division by zero. Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
#
9443f2c8 |
| 29-Jun-2020 |
Lee Jones <lee.jones@linaro.org> |
pwm: bcm-iproc: Remove impossible comparison when validating duty cycle 'duty' here is an unsigned int, thus checking for <0 will always evaluate to false. Fixes the following W
pwm: bcm-iproc: Remove impossible comparison when validating duty cycle 'duty' here is an unsigned int, thus checking for <0 will always evaluate to false. Fixes the following W=1 warning: drivers/pwm/pwm-bcm-iproc.c:147:12: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-pwm@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> 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 |
|
#
24906a41 |
| 17-Oct-2019 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pwm: bcm-iproc: Prevent unloading the driver module while in use The owner member of struct pwm_ops must be set to THIS_MODULE to increase the reference count of the module such that the
pwm: bcm-iproc: Prevent unloading the driver module while in use The owner member of struct pwm_ops must be set to THIS_MODULE to increase the reference count of the module such that the module cannot be removed while its code is in use. Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|
Revision tags: v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, 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(). Consid
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 ...
|
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, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4 |
|
#
daa5abc4 |
| 05-Jul-2016 |
Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> |
pwm: Add support for Broadcom iProc PWM controller Add support for the PWM controller present in Broadcom's iProc family of SoCs. It has been tested on the Northstar+ bcm958625HR board.
pwm: Add support for Broadcom iProc PWM controller Add support for the PWM controller present in Broadcom's iProc family of SoCs. It has been tested on the Northstar+ bcm958625HR board. Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> [thierry.reding@gmail.com: bunch of coding style fixes, cleanups] Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
show more ...
|