summaryrefslogtreecommitdiff
path: root/drivers/pwm
AgeCommit message (Collapse)AuthorFilesLines
2025-02-17pwm: microchip-core: fix incorrect comparison with max periodConor Dooley1-1/+1
commit 752b6e3af374460a2de18f0c10bfa06bf844dbe8 upstream. In mchp_core_pwm_apply_locked(), if hw_period_steps is equal to its max, an error is reported and .apply fails. The max value is actually a permitted value however, and so this check can fail where multiple channels are enabled. For example, the first channel to be configured requests a period that sets hw_period_steps to the maximum value, and when a second channel is enabled the driver reads hw_period_steps back from the hardware and finds it to be the maximum possible value, triggering the warning on a permitted value. The value to be avoided is 255 (PERIOD_STEPS_MAX + 1), as that will produce undesired behaviour, so test for greater than, rather than equal to. Fixes: 2bf7ecf7b4ff ("pwm: add microchip soft ip corePWM driver") Cc: stable@vger.kernel.org Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250122-pastor-fancied-0b993da2d2d2@spud Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-08pwm: stm32: Add check for clk_enable()Mingwei Zheng1-2/+5
[ Upstream commit e8c59791ebb60790c74b2c3ab520f04a8a57219a ] Add check for the return value of clk_enable() to catch the potential error. Fixes: 19f1016ea960 ("pwm: stm32: Fix enable count for clk in .probe()") Signed-off-by: Mingwei Zheng <zmw12306@gmail.com> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Link: https://lore.kernel.org/r/20241215224752.220318-1-zmw12306@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08pwm: stm32-lp: Add check for clk_enable()Mingwei Zheng1-2/+6
[ Upstream commit cce16e7f6216227964cda25f5f23634bce2c500f ] Add check for the return value of clk_enable() to catch the potential error. We used APP-Miner to find it. Fixes: e70a540b4e02 ("pwm: Add STM32 LPTimer PWM driver") Signed-off-by: Mingwei Zheng <zmw12306@gmail.com> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Link: https://lore.kernel.org/r/20241206215318.3402860-1-zmw12306@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08of: remove internal arguments from of_property_for_each_u32()Luca Ceresoli1-3/+1
[ Upstream commit 9722c3b66e21ff08aec570d02a97d331087fd70f ] The of_property_for_each_u32() macro needs five parameters, two of which are primarily meant as internal variables for the macro itself (in the for() clause). Yet these two parameters are used by a few drivers, and this can be considered misuse or at least bad practice. Now that the kernel uses C11 to build, these two parameters can be avoided by declaring them internally, thus changing this pattern: struct property *prop; const __be32 *p; u32 val; of_property_for_each_u32(np, "xyz", prop, p, val) { ... } to this: u32 val; of_property_for_each_u32(np, "xyz", val) { ... } However two variables cannot be declared in the for clause even with C11, so declare one struct that contain the two variables we actually need. As the variables inside this struct are not meant to be used by users of this macro, give the struct instance the noticeable name "_it" so it is visible during code reviews, helping to avoid new code to use it directly. Most usages are trivially converted as they do not use those two parameters, as expected. The non-trivial cases are: - drivers/clk/clk.c, of_clk_get_parent_name(): easily doable anyway - drivers/clk/clk-si5351.c, si5351_dt_parse(): this is more complex as the checks had to be replicated in a different way, making code more verbose and somewhat uglier, but I refrained from a full rework to keep as much of the original code untouched having no hardware to test my changes All the changes have been build tested. The few for which I have the hardware have been runtime-tested too. Reviewed-by: Andre Przywara <andre.przywara@arm.com> # drivers/clk/sunxi/clk-simple-gates.c, drivers/clk/sunxi/clk-sun8i-bus-gates.c Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> # drivers/gpio/gpio-brcmstb.c Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> # drivers/irqchip/irq-atmel-aic-common.c Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # drivers/iio/adc/ti_am335x_adc.c Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> # drivers/pwm/pwm-samsung.c Acked-by: Richard Leitner <richard.leitner@linux.dev> # drivers/usb/misc/usb251xb.c Acked-by: Mark Brown <broonie@kernel.org> # sound/soc/codecs/arizona.c Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> # sound/soc/codecs/arizona.c Acked-by: Michael Ellerman <mpe@ellerman.id.au> # arch/powerpc/sysdev/xive/spapr.c Acked-by: Stephen Boyd <sboyd@kernel.org> # clk Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Acked-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20240724-of_property_for_each_u32-v3-1-bea82ce429e2@bootlin.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Stable-dep-of: 28fa3291cad1 ("clk: fix an OF node reference leak in of_clk_get_parent_name()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09pwm: imx27: Workaround of the pwm output bug when decrease the duty cycleClark Wang1-2/+96
[ Upstream commit a25351e4c7740eb22561a3ee4ef17611c6f410b0 ] Implement workaround for ERR051198 (https://www.nxp.com/docs/en/errata/IMX8MN_0N14Y.pdf) PWM output may not function correctly if the FIFO is empty when a new SAR value is programmed. Description: When the PWM FIFO is empty, a new value programmed to the PWM Sample register (PWM_PWMSAR) will be directly applied even if the current timer period has not expired. If the new SAMPLE value programmed in the PWM_PWMSAR register is less than the previous value, and the PWM counter register (PWM_PWMCNR) that contains the current COUNT value is greater than the new programmed SAMPLE value, the current period will not flip the level. This may result in an output pulse with a duty cycle of 100%. Workaround: Program the current SAMPLE value in the PWM_PWMSAR register before updating the new duty cycle to the SAMPLE value in the PWM_PWMSAR register. This will ensure that the new SAMPLE value is modified during a non-empty FIFO, and can be successfully updated after the period expires. Write the old SAR value before updating the new duty cycle to SAR. This avoids writing the new value into an empty FIFO. This only resolves the issue when the PWM period is longer than 2us (or <500kHz) because write register is not quick enough when PWM period is very short. Reproduce steps: cd /sys/class/pwm/pwmchip1/pwm0 echo 2000000000 > period # It is easy to observe by using long period echo 1000000000 > duty_cycle echo 1 > enable echo 8000 > duty_cycle # One full high pulse will be seen by scope Fixes: 166091b1894d ("[ARM] MXC: add pwm driver for i.MX SoCs") Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241008194123.1943141-1-Frank.Li@nxp.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-14pwm: imx-tpm: Use correct MODULO value for EPWM modeErik Schumacher1-1/+3
commit cc6a931d1f3b412263d515fd93b21fc0ca5147fe upstream. The modulo register defines the period of the edge-aligned PWM mode (which is the only mode implemented). The reference manual states: "The EPWM period is determined by (MOD + 0001h) ..." So the value that is written to the MOD register must therefore be one less than the calculated period length. Return -EINVAL if the calculated length is already zero. A correct MODULO value is particularly relevant if the PWM has to output a high frequency due to a low period value. Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support") Cc: stable@vger.kernel.org Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com> Link: https://lore.kernel.org/r/1a3890966d68b9f800d457cbf095746627495e18.camel@iris-sensing.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03pwm: atmel-tcb: Fix race condition and convert to guardsUwe Kleine-König1-7/+5
[ Upstream commit 37f7707077f5ea2515bf4b1dc7fad43f8e12993e ] The hardware only supports a single period length for both PWM outputs. So atmel_tcb_pwm_config() checks the configuration of the other output if it's compatible with the currently requested setting. The register values are then actually updated in atmel_tcb_pwm_enable(). To make this race free the lock must be held during the whole process, so grab the lock in .apply() instead of individually in atmel_tcb_pwm_disable() and atmel_tcb_pwm_enable() which then also covers atmel_tcb_pwm_config(). To simplify handling, use the guard helper to let the compiler care for unlocking. Otherwise unlocking would be more difficult as there is more than one exit path in atmel_tcb_pwm_apply(). Fixes: 9421bade0765 ("pwm: atmel: add Timer Counter Block PWM driver") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20240709101806.52394-3-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03pwm: stm32: Always do lazy disablingUwe Kleine-König1-2/+3
[ Upstream commit 7346e7a058a2c9aa9ff1cc699c7bf18a402d9f84 ] When the state changes from enabled to disabled, polarity, duty_cycle and period are not configured in hardware and TIM_CCER_CCxE is just cleared. However if the state changes from one disabled state to another, all parameters are written to hardware because the early exit from stm32_pwm_apply() is only taken if the pwm is currently enabled. This yields surprises like: Applying { .period = 1, .duty_cycle = 0, .enabled = false } succeeds if the pwm is initially on, but fails if it's already off because 1 is a too small period. Update the check for lazy disable to always exit early if the target state is disabled, no matter what is currently configured. Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240703110010.672654-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-07-05pwm: stm32: Refuse too small period requestsUwe Kleine-König1-0/+3
commit c45fcf46ca2368dafe7e5c513a711a6f0f974308 upstream. If period_ns is small, prd might well become 0. Catch that case because otherwise with regmap_write(priv->regmap, TIM_ARR, prd - 1); a few lines down quite a big period is configured. Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm") Cc: stable@vger.kernel.org Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/b86f62f099983646f97eeb6bfc0117bb2d0c340d.1718979150.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()Sean Young4-16/+16
[ Upstream commit c748a6d77c06a78651030e17da6beb278a1c9470 ] In order to introduce a pwm api which can be used from atomic context, we will need two functions for applying pwm changes: int pwm_apply_might_sleep(struct pwm *, struct pwm_state *); int pwm_apply_atomic(struct pwm *, struct pwm_state *); This commit just deals with renaming pwm_apply_state(), a following commit will introduce the pwm_apply_atomic() function. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Stable-dep-of: 974afccd3794 ("leds: pwm: Disable PWM when going to suspend") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12pwm: sti: Simplify probe function using devm functionsUwe Kleine-König1-36/+3
[ Upstream commit 5bb0b194aeee5d5da6881232f4e9989b35957c25 ] Instead of of_clk_get_by_name() use devm_clk_get_prepared() which has several advantages: - Combines getting the clock and a call to clk_prepare(). The latter can be dropped from sti_pwm_probe() accordingly. - Cares for calling clk_put() which is missing in both probe's error path and the remove function. - Cares for calling clk_unprepare() which can be dropped from the error paths and the remove function. (Note that not all error path got this right.) With additionally using devm_pwmchip_add() instead of pwmchip_add() the remove callback can be dropped completely. With it the last user of platform_get_drvdata() goes away and so platform_set_drvdata() can be dropped from the probe function, too. Fixes: 378fe115d19d ("pwm: sti: Add new driver for ST's PWM IP") Link: https://lore.kernel.org/r/81f0e1d173652f435afda6719adaed1922fe059a.1710068192.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12pwm: sti: Prepare removing pwm_chip from driver dataUwe Kleine-König1-7/+10
[ Upstream commit 54272761ce7c475fa30a31b59b0cb89f7652b39e ] This prepares the driver for further changes that will drop struct pwm_chip chip from struct sti_pwm_chip. Use the pwm_chip as driver data instead of the sti_pwm_chip to get access to the pwm_chip in sti_pwm_remove() without using pc->chip. Link: https://lore.kernel.org/r/56d53372aacff6871df4d6c6779c9dac94592696.1707900770.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Stable-dep-of: 5bb0b194aeee ("pwm: sti: Simplify probe function using devm functions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-03pwm: img: fix pwm clock lookupZoltan HERPAI1-2/+2
[ Upstream commit 9eb05877dbee03064d3d3483cd6702f610d5a358 ] 22e8e19 has introduced a regression in the imgchip->pwm_clk lookup, whereas the clock name has also been renamed to "imgchip". This causes the driver failing to load: [ 0.546905] img-pwm 18101300.pwm: failed to get imgchip clock [ 0.553418] img-pwm: probe of 18101300.pwm failed with error -2 Fix this lookup by reverting the clock name back to "pwm". Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu> Link: https://lore.kernel.org/r/20240320083602.81592-1-wigyori@uid0.hu Fixes: 22e8e19a46f7 ("pwm: img: Rename variable pointing to driver private data") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26pwm: sti: Fix capture for st,pwm-num-chan < st,capture-num-chanUwe Kleine-König1-1/+10
[ Upstream commit 5f623835584f1c8d1030666796f40c47a448ce0b ] The driver only used the number of pwm channels to set the pwm_chip's npwm member. The result is that if there are more capture channels than PWM channels specified in the device tree, only a part of the capture channel is usable. Fix that by passing the bigger channel count to the pwm framework. This makes it possible that the .apply() callback is called with .hwpwm >= pwm_num_devs, catch that case and return an error code. Fixes: c97267ae831d ("pwm: sti: Add PWM capture callback") Link: https://lore.kernel.org/r/20240204212043.2951852-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-26pwm: atmel-hlcdc: Fix clock imbalance related to suspend supportUwe Kleine-König1-1/+1
[ Upstream commit e25ac87d3f831fed002c34aadddaf4ebb4ea45ec ] The suspend callback disables the periph clock when the PWM is enabled and resume reenables this clock if the PWM was disabled before. Judging from the code comment it's suspend that is wrong here. Fix accordingly. Fixes: f9bb9da7c09d ("pwm: atmel-hlcdc: Implement the suspend/resume hooks") Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/b51ea92b0a45eff3dc83b08adefd43d930df996c.1706269232.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-25pwm: Fix out-of-bounds access in of_pwm_single_xlate()Uwe Kleine-König1-1/+1
commit a297d07b9a1e4fb8cda25a4a2363a507d294b7c9 upstream. With args->args_count == 2 args->args[2] is not defined. Actually the flags are contained in args->args[1]. Fixes: 3ab7b6ac5d82 ("pwm: Introduce single-PWM of_xlate function") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/243908750d306e018a3d4bf2eb745d53ab50f663.1704835845.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-25pwm: jz4740: Don't use dev_err_probe() in .request()Uwe Kleine-König1-3/+4
commit 9320fc509b87b4d795fb37112931e2f4f8b5c55f upstream. dev_err_probe() is only supposed to be used in probe functions. While it probably doesn't hurt, both the EPROBE_DEFER handling and calling device_set_deferred_probe_reason() are conceptually wrong in the request callback. So replace the call by dev_err() and a separate return statement. This effectively reverts commit c0bfe9606e03 ("pwm: jz4740: Simplify with dev_err_probe()"). Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240106141302.1253365-2-u.kleine-koenig@pengutronix.de Fixes: c0bfe9606e03 ("pwm: jz4740: Simplify with dev_err_probe()") Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-25pwm: stm32: Fix enable count for clk in .probe()Philipp Zabel1-4/+14
[ Upstream commit 19f1016ea9600ed89bc24247c36ff5934ad94fbb ] Make the driver take over hardware state without disabling in .probe() and enable the clock for each enabled channel. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> [ukleinek: split off from a patch that also implemented .get_state()] Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm") Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-25pwm: stm32: Use hweight32 in stm32_pwm_detect_channelsPhilipp Zabel1-15/+2
[ Upstream commit 41fa8f57c0d269243fe3bde2bce71e82c884b9ad ] Use hweight32() to count the CCxE bits in stm32_pwm_detect_channels(). Since the return value is assigned to chip.npwm, change it to unsigned int as well. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Stable-dep-of: 19f1016ea960 ("pwm: stm32: Fix enable count for clk in .probe()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20pwm: brcmstb: Utilize appropriate clock APIs in suspend/resumeFlorian Fainelli1-2/+2
[ Upstream commit e9bc4411548aaa738905d37851a0146c16b3bb21 ] The suspend/resume functions currently utilize clk_disable()/clk_enable() respectively which may be no-ops with certain clock providers such as SCMI. Fix this to use clk_disable_unprepare() and clk_prepare_enable() respectively as we should. Fixes: 3a9f5957020f ("pwm: Add Broadcom BCM7038 PWM controller support") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20pwm: sti: Reduce number of allocations and drop usage of chip_dataUwe Kleine-König1-15/+14
[ Upstream commit 2d6812b41e0d832919d72c72ebddf361df53ba1b ] Instead of using one allocation per capture channel, use a single one. Also store it in driver data instead of chip data. This has several advantages: - driver data isn't cleared when pwm_put() is called - Reduces memory fragmentation Also register the pwm chip only after the per capture channel data is initialized as the capture callback relies on this initialization and it might be called even before pwmchip_add() returns. It would be still better to have struct sti_pwm_compat_data and the per-channel data struct sti_cpt_ddata in a single memory chunk, but that's not easily possible because the number of capture channels isn't known yet when the driver data struct is allocated. Fixes: e926b12c611c ("pwm: Clear chip_data in pwm_put()") Reported-by: George Stark <gnstark@sberdevices.ru> Fixes: c97267ae831d ("pwm: sti: Add PWM capture callback") Link: https://lore.kernel.org/r/20230705080650.2353391-7-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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-07Merge tag 'pwm/for-6.6-rc1' of ↵Linus Torvalds36-260/+221
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "Various cleanups and fixes across the board" * tag 'pwm/for-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (31 commits) pwm: lpc32xx: Remove handling of PWM channels pwm: atmel: Simplify using devm functions dt-bindings: pwm: brcm,kona-pwm: convert to YAML pwm: stmpe: Handle errors when disabling the signal pwm: stm32: Simplify using devm_pwmchip_add() pwm: stm32: Don't modify HW state in .remove() callback pwm: Fix order of freeing resources in pwmchip_remove() pwm: ntxec: Use device_set_of_node_from_dev() pwm: ntxec: Drop a write-only variable from driver data pwm: pxa: Don't reimplement of_device_get_match_data() pwm: lpc18xx-sct: Simplify using devm_clk_get_enabled() pwm: atmel-tcb: Don't track polarity in driver data pwm: atmel-tcb: Unroll atmel_tcb_pwm_set_polarity() into only caller pwm: atmel-tcb: Put per-channel data into driver data pwm: atmel-tcb: Fix resource freeing in error path and remove pwm: atmel-tcb: Harmonize resource allocation order pwm: Drop unused #include <linux/radix-tree.h> pwm: rz-mtu3: Fix build warning 'num_channel_ios' not described pwm: Remove outdated documentation for pwmchip_remove() pwm: atmel: Enable clk when pwm already enabled in bootloader ...
2023-08-22pwm: lpc32xx: Remove handling of PWM channelsVladimir Zapolskiy1-8/+8
Because LPC32xx PWM controllers have only a single output which is registered as the only PWM device/channel per controller, it is known in advance that pwm->hwpwm value is always 0. On basis of this fact simplify the code by removing operations with pwm->hwpwm, there is no controls which require channel number as input. Even though I wasn't aware at the time when I forward ported that patch, this fixes a null pointer dereference as lpc32xx->chip.pwms is NULL before devm_pwmchip_add() is called. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 3d2813fb17e5 ("pwm: lpc32xx: Don't modify HW state in .probe() after the PWM chip was registered") Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-08-18mfd: rz-mtu3: Link time dependenciesArnd Bergmann1-1/+1
The new set of drivers for RZ/G2L MTU3a tries to enable compile-testing the individual client drivers even when the MFD portion is disabled but gets it wrong, causing a link failure when the core is in a loadable module but the other drivers are built-in: x86_64-linux-ld: drivers/pwm/pwm-rz-mtu3.o: in function `rz_mtu3_pwm_apply': pwm-rz-mtu3.c:(.text+0x4bf): undefined reference to `rz_mtu3_8bit_ch_write' x86_64-linux-ld: pwm-rz-mtu3.c:(.text+0x509): undefined reference to `rz_mtu3_disable' arm-linux-gnueabi-ld: drivers/counter/rz-mtu3-cnt.o: in function `rz_mtu3_cascade_counts_enable_get': rz-mtu3-cnt.c:(.text+0xbec): undefined reference to `rz_mtu3_shared_reg_read' It seems better not to add the extra complexity here but instead just use a normal hard dependency, so remove the #else portion in the header along with the "|| COMPILE_TEST". This could also be fixed by having slightly more elaborate Kconfig dependencies or using the cursed 'IS_REACHABLE()' helper, but in practice it's already possible to compile-test all these drivers by enabling the mtd portion. Fixes: 254d3a727421c ("pwm: Add Renesas RZ/G2L MTU3a PWM driver") Fixes: 0be8907359df4 ("counter: Add Renesas RZ/G2L MTU3a counter driver") Fixes: 654c293e1687b ("mfd: Add Renesas RZ/G2L MTU3a core driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230719090430.1925182-1-arnd@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-07-28pwm: atmel: Simplify using devm functionsUwe Kleine-König1-26/+7
For all resources used by the driver there is a devm variant to allocate these. This simplifies the error path in the probe callback and allows to drop the remove callback. While at it also use dev_err_probe() to compact returning an error. With the remove callback gone, there is no user of driver data left, so the call to platform_set_drvdata() can also be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: stmpe: Handle errors when disabling the signalUwe Kleine-König1-8/+9
Before the pwm framework implementedatomic updates (with the .apply() callback) the .disable() callback returned void. This is still visible in the stmpe driver which drops errors in the disable path. Improve the driver to forward failures in stmpe_24xx_pwm_disable() to the caller of pwm_apply_state(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: stm32: Simplify using devm_pwmchip_add()Uwe Kleine-König1-9/+1
This allows to drop the platform_driver's remove function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: stm32: Don't modify HW state in .remove() callbackUwe Kleine-König1-4/+0
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>
2023-07-28pwm: Fix order of freeing resources in pwmchip_remove()Uwe Kleine-König1-3/+3
pwmchip_add() calls of_pwmchip_add() only after adding the chip to pwm_chips and releasing pwm_lock. So the proper order in pwmchip_remove() is to call of_pwmchip_remove() before taking the mutex and removing the chip from pwm_chips. This way pwmchip_remove() releases the resources in reverse order compared to pwmchip_add() requesting them. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: ntxec: Use device_set_of_node_from_dev()Uwe Kleine-König1-1/+1
Compared to overwriting pdev->dev.of_node directly, this takes care of reference counting. It also prevents that the parent device matches this driver. See commit 9b22c17a3cc5 ("of: Check 'of_node_reused' flag on of_match_device()") for further details. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: ntxec: Drop a write-only variable from driver dataUwe Kleine-König1-2/+0
.dev is assigned in .probe() and never read. So it serves no purpose and can be removed. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: pxa: Don't reimplement of_device_get_match_data()Uwe Kleine-König1-8/+1
Apart from the return type pxa_pwm_get_id_dt() reimplements of_device_get_match_data(). Drop the former and replace the call to it by the latter. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: lpc18xx-sct: Simplify using devm_clk_get_enabled()Uwe Kleine-König1-25/+8
With devm_clk_get_enabled() the call to clk_disable_unprepare() can be dropped from the error path and the remove callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: atmel-tcb: Don't track polarity in driver dataUwe Kleine-König1-12/+6
struct atmel_tcb_pwm_device::polarity is only used in atmel_tcb_pwm_enable and atmel_tcb_pwm_disable(). These functions are only called by atmel_tcb_pwm_apply() after the member variable was assigned to state->polarity. So the value assigned in atmel_tcb_pwm_request() is never used and the member can be dropped from struct atmel_tcb_pwm_device. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: atmel-tcb: Unroll atmel_tcb_pwm_set_polarity() into only callerUwe Kleine-König1-14/+3
atmel_tcb_pwm_set_polarity() is only called once and effectively wraps an assignment only. Replace the function call by the respective assignment. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: atmel-tcb: Put per-channel data into driver dataUwe Kleine-König1-20/+9
This simplifies the code, reduces the number of memory allocations and pointer dereferences. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: atmel-tcb: Fix resource freeing in error path and removeUwe Kleine-König1-6/+17
Several resources were not freed in the error path and the remove function. Add the forgotten items. Fixes: 34cbcd72588f ("pwm: atmel-tcb: Add sama5d2 support") Fixes: 061f8572a31c ("pwm: atmel-tcb: Switch to new binding") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: atmel-tcb: Harmonize resource allocation orderUwe Kleine-König1-29/+20
Allocate driver data as first resource in the probe function. This way it can be used during allocation of the other resources (instead of assigning these to local variables first and update driver data only when it's allocated). Also as driver data is allocated using a devm function this should happen first to have the order of freeing resources in the error path and the remove function in reverse. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: Drop unused #include <linux/radix-tree.h>Uwe Kleine-König1-1/+0
core.c doens't use any of the symbols provided by linux/radix-tree.h and compiles just fine without this include. So drop the #include. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: rz-mtu3: Fix build warning 'num_channel_ios' not describedBiju Das1-1/+1
Fix the below build warning: warning: Function parameter or member 'num_channel_ios' not described in 'rz_mtu3_channel_io_map' Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-28pwm: Remove outdated documentation for pwmchip_remove()Uwe Kleine-König1-4/+1
pwmchip_remove() returns void since some time but the documentation still mentions the situations where it used to return an error code. Just remove this old and now wrong text. Fixes: 8083f58d08fd ("pwm: 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>
2023-07-24pwm: atmel: Enable clk when pwm already enabled in bootloaderGuiting Shen1-2/+45
The driver would never call clk_enable() if the PWM channel was already enabled in bootloader which lead to dump the warning message "the PWM clock already disabled" when turning off the PWM channel. Add atmel_pwm_enable_clk_if_on() in probe function to enable clock if the PWM channel was already enabled in bootloader. Signed-off-by: Guiting Shen <aarongt.shen@gmail.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-24pwm: Explicitly include correct DT includesRob Herring28-21/+21
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-21pwm: sl28cpld: Consistently name pwm_chip variables "chip"Uwe Kleine-König1-5/+8
Nearly all PWM drivers use the name "chip" for the member in the driver struct pointing to the pwm_chip. Also all local variables and function parameters with this type use this name. Rename the struct pwm_chip member accordingly for consistency. Also rename the parameter of the macro sl28cpld_pwm_from_chip to "chip". Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-21pwm: sifive: Consistently name pwm_chip variables "chip"Uwe Kleine-König1-2/+2
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>
2023-07-21pwm: rockchip: Consistently name pwm_chip variables "chip"Uwe Kleine-König1-2/+2
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>
2023-07-21pwm: lp3943: Consistently name pwm_chip variables "chip"Uwe Kleine-König1-2/+2
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>
2023-07-21pwm: cros-ec: Consistently name pwm_chip variables "chip"Uwe Kleine-König1-5/+5
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 two variables that have a different name to be called "chip", too, for consistency. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-07-21pwm: crc: Consistently name pwm_chip variables "chip"Uwe Kleine-König1-2/+2
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>
2023-07-21pwm: bcm-kona: Consistently name pwm_chip variables "chip"Uwe Kleine-König1-2/+2
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>