| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
.get_state() can return an error indication. Make use of it to propagate
failing hardware accesses.
Reviewed-by: Baolin Wang <[email protected]>
Acked-by: Conor Dooley <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
.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 <[email protected]>
Reviewed-by: Baolin Wang <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Nobuhiro Iwamatsu <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
Reviewed-by: Dave Stevenson <[email protected]>
Acked-by: Douglas Anderson <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Acked-by: Conor Dooley <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
As the last call to sprd_pwm_apply() might have exited early if
state->enabled was false, the values for period and duty_cycle stored in
pwm->state might not have been written to hardware and it must be
ensured that they are configured before enabling the PWM.
Fixes: 8aae4b02e8a6 ("pwm: sprd: Add Spreadtrum PWM support")
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
pwmchip_remove() returns always 0. Don't use the value to make it
possible to eventually change the function to return void. This is a
good thing as pwmchip_remove() is usually called from a remove function
(mostly for platform devices) and their return value is ignored by the
device core anyhow.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
The driver only supports normal polarity and so should refuse requests
for inversed polarity.
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Chunyan Zhang <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Acked-by: Chunyan Zhang <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|
|
This patch adds the Spreadtrum PWM support, which provides maximum 4
channels.
Signed-off-by: Neo Hou <[email protected]>
Signed-off-by: Baolin Wang <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
|