- Sep 03, 2021
-
-
Uwe Kleine-König authored
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of pwm_imx_tpm_remove(). Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of pwm_imx_tpm_remove(). Signed-off-by:
-
Uwe Kleine-König authored
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of cros_ec_pwm_remove(). Signed-off-by:
-
Uwe Kleine-König authored
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of brcmstb_pwm_remove(). Signed-off-by:
-
Uwe Kleine-König authored
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of atmel_tcb_pwm_remove() and considers the device removed anyhow. So returning early results in a resource leak. Signed-off-by:
-
Uwe Kleine-König authored
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. Also the driver core ignores the return value of atmel_hlcdc_pwm_remove() and considers the device removed anyhow. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
With devm_pwmchip_add() there is no need to explicitly call pwmchip_remove(), so this call can be dropped from the remove callback. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
This allows to drop the platform_driver's remove function. This is the only user of driver data so this can go away, too. Signed-off-by:
-
Uwe Kleine-König authored
There are no arm64 specific constructs in this driver and it compiles just fine with ARCH=arm. Signed-off-by:
-
Uwe Kleine-König authored
There are no mips specific constructs in this driver and it compiles just fine with ARCH=arm. Signed-off-by:
-
Uwe Kleine-König authored
Since commit f9a8ee8c ("pwm: Always allocate PWM chip base ID dynamically") there is no effect any more for assigning this variable. When the patch resulting in f9a8ee8c was created, this driver didn't exist yet, so this was missed. Signed-off-by:
-
Uwe Kleine-König authored
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 ehrpwm_pwm_remove() a bit simpler and eventually allows to make pwmchip_remove() return void. Signed-off-by:
-
Uwe Kleine-König authored
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 authored
The driver is supposed to stay functional until pwmchip_remove() returns. So disable clocks and reset the hardware only after that. The return value of pwmchip_remove doesn't need to be checked because it returns zero anyhow and should be changed to return void eventually. Signed-off-by:
-
Uwe Kleine-König authored
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 authored
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 authored
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 authored
This fixes a race condition: After pwmchip_add() is called there might already be a consumer and then modifying the hardware behind the consumer's back is bad. So reset before calling pwmchip_add(). Note that reseting the hardware isn't the right thing to do if the PWM is already running as it might e.g. disable (or even enable) a backlight that is supposed to be on (or off). Fixes: 4dce82c1 ("pwm: add pwm-mxs support") Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Uwe Kleine-König authored
This fixes a race condition: After pwmchip_add() is called there might already be a consumer and then modifying the hardware behind the consumer's back is bad. So set the default before. (Side-note: I don't know what this register setting actually does, if this modifies the polarity there is an inconsistency because the inversed polarity isn't considered if the PWM is already running during .probe().) Fixes: acfd92fd ("pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value") Cc: Sylvain Lemieux <slemieux@tycoint.com> Signed-off-by:
-
Uwe Kleine-König authored
The assumption that lead to commit 5e5da1e9 ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") was wrong: The pwm-ab8500 devices are not directly instantiated from device tree, but from the ab8500 mfd driver. So the pdev->id isn't -1, but a number between 1 and 3. Now that pwmchip ids are always allocated dynamically, this cannot easily be reverted. Introduce a new member in the driver data struct that tracks the hardware id and use this to calculate the register offset. Side-note: Using chip->base to calculate the offset was never robust because if there was already a PWM with id 1 at the time ab8500-pwm.1 was probed, the associated pwmchip would get assigned chip->base = 2 (or something bigger). Fixes: 5e5da1e9 ("pwm: ab8500: Explicitly allocate pwm chip base dynamically") Fixes: 6173f8f4 ("pwm: Move AB8500 PWM driver to PWM framework") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Uwe Kleine-König authored
This improves the driver's behavior in several ways: - The lock is held for shorter periods and so a channel that is currently waited for doesn't block disabling another channel. - It's easier to understand because the procedure is split into more semantic units and documentation is improved - A channel is only set to pending when such an event is actually scheduled in hardware (by writing the CUPD register). - Also wait in .get_state() to report the last configured state instead of (maybe) the previous one. This fixes the read back duty cycle and so prevents a warning being emitted when PWM_DEBUG is on. Tested on an AriettaG25. Signed-off-by:
-
