* [PATCH 01/14] pwm: bcm2835: Improve period and duty cycle calculation
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 02/14] pwm: bcm-kona: Use pwmchip_add() instead of pwmchip_add_with_polarity() Uwe Kleine-König
` (13 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel, Lino Sanfilippo
With an input clk rate bigger than 2000000000, scaler would have been
zero which then would have resulted in a division by zero.
Also the originally implemented algorithm divided by the result of a
division. This nearly always looses precision. Consider a requested period
of 1000000 ns. With an input clock frequency of 32786885 Hz the hardware
was configured with an actual period of 983869.007 ns (PERIOD = 32258)
while the hardware can provide 1000003.508 ns (PERIOD = 32787).
And note if the input clock frequency was 32786886 Hz instead, the hardware
was configured to 1016656.477 ns (PERIOD = 33333) while the optimal
setting results in 1000003.477 ns (PERIOD = 32787).
This patch implements proper range checking and only divides once for
the calculation of period (and similar for duty_cycle).
Reviewed-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Tested-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Link: https://lore.kernel.org/r/20210114204804.143892-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/pwm-bcm2835.c | 35 +++++++++++++++++++++++++++--------
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index 6ff5f04b3e07..d593cce249d9 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -64,8 +64,9 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
unsigned long rate = clk_get_rate(pc->clk);
- unsigned long long period;
- unsigned long scaler;
+ unsigned long long period_cycles;
+ u64 max_period;
+
u32 val;
if (!rate) {
@@ -73,18 +74,36 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
return -EINVAL;
}
- scaler = DIV_ROUND_CLOSEST(NSEC_PER_SEC, rate);
+ /*
+ * period_cycles must be a 32 bit value, so period * rate / NSEC_PER_SEC
+ * must be <= U32_MAX. As U32_MAX * NSEC_PER_SEC < U64_MAX the
+ * multiplication period * rate doesn't overflow.
+ * To calculate the maximal possible period that guarantees the
+ * above inequality:
+ *
+ * round(period * rate / NSEC_PER_SEC) <= U32_MAX
+ * <=> period * rate / NSEC_PER_SEC < U32_MAX + 0.5
+ * <=> period * rate < (U32_MAX + 0.5) * NSEC_PER_SEC
+ * <=> period < ((U32_MAX + 0.5) * NSEC_PER_SEC) / rate
+ * <=> period < ((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate
+ * <=> period <= ceil((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate) - 1
+ */
+ max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC / 2, rate) - 1;
+
+ if (state->period > max_period)
+ return -EINVAL;
+
/* set period */
- period = DIV_ROUND_CLOSEST_ULL(state->period, scaler);
+ period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * rate, NSEC_PER_SEC);
- /* dont accept a period that is too small or has been truncated */
- if ((period < PERIOD_MIN) || (period > U32_MAX))
+ /* don't accept a period that is too small */
+ if (period_cycles < PERIOD_MIN)
return -EINVAL;
- writel(period, pc->base + PERIOD(pwm->hwpwm));
+ writel(period_cycles, pc->base + PERIOD(pwm->hwpwm));
/* set duty cycle */
- val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle, scaler);
+ val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * rate, NSEC_PER_SEC);
writel(val, pc->base + DUTY(pwm->hwpwm));
/* set polarity */
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 02/14] pwm: bcm-kona: Use pwmchip_add() instead of pwmchip_add_with_polarity()
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 01/14] pwm: bcm2835: Improve period and duty cycle calculation Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 03/14] pwm: atmel-hlcdc: " Uwe Kleine-König
` (12 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel, Uwe Kleine-König
From: Uwe Kleine-König <uwe@kleine-koenig.org>
The only side effect of this change is that pwm->state.polarity is
initialized to PWM_POLARITY_NORMAL instead of PWM_POLARITY_INVERSED.
However all other members of pwm->state are uninitialized and consumers
are expected to provide the right polarity (either by setting it explicitly
or by using a helper like pwm_init_state() that overwrites .polarity
anyhow with a value independent of the initial value).
The eventual goal is to remove pwmchip_add_with_polarity() and so simplify
the data flow in the PWM core.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20201207134556.25217-2-uwe@kleine-koenig.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/pwm-bcm-kona.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
index 578b3621c97e..717b55677573 100644
--- a/drivers/pwm/pwm-bcm-kona.c
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -301,7 +301,7 @@ static int kona_pwmc_probe(struct platform_device *pdev)
clk_disable_unprepare(kp->clk);
- ret = pwmchip_add_with_polarity(&kp->chip, PWM_POLARITY_INVERSED);
+ ret = pwmchip_add(&kp->chip);
if (ret < 0)
dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 03/14] pwm: atmel-hlcdc: Use pwmchip_add() instead of pwmchip_add_with_polarity()
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 01/14] pwm: bcm2835: Improve period and duty cycle calculation Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 02/14] pwm: bcm-kona: Use pwmchip_add() instead of pwmchip_add_with_polarity() Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 04/14] pwm: Drop function pwmchip_add_with_polarity() Uwe Kleine-König
` (11 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel, Uwe Kleine-König
From: Uwe Kleine-König <uwe@kleine-koenig.org>
The only side effect of this change is that pwm->state.polarity is
initialized to PWM_POLARITY_NORMAL instead of PWM_POLARITY_INVERSED.
However all other members of pwm->state are uninitialized and consumers
are expected to provide the right polarity (either by setting it explicitly
or by using a helper like pwm_init_state() that overwrites .polarity
anyhow with a value independent of the initial value).
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20201207134556.25217-3-uwe@kleine-koenig.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/pwm-atmel-hlcdc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
index dcbc0489dfd4..4551aa2c484c 100644
--- a/drivers/pwm/pwm-atmel-hlcdc.c
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -270,7 +270,7 @@ static int atmel_hlcdc_pwm_probe(struct platform_device *pdev)
chip->chip.of_xlate = of_pwm_xlate_with_flags;
chip->chip.of_pwm_n_cells = 3;
- ret = pwmchip_add_with_polarity(&chip->chip, PWM_POLARITY_INVERSED);
+ ret = pwmchip_add(&chip->chip);
if (ret) {
clk_disable_unprepare(hlcdc->periph_clk);
return ret;
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 04/14] pwm: Drop function pwmchip_add_with_polarity()
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (2 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 03/14] pwm: atmel-hlcdc: " Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 05/14] pwm: ab8500: Implement .apply instead of .config, .enable and .disable Uwe Kleine-König
` (10 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel, Uwe Kleine-König
From: Uwe Kleine-König <uwe@kleine-koenig.org>
pwmchip_add() only calls pwmchip_add_with_polarity() and nothing else. All
other users of pwmchip_add_with_polarity() are gone. So drop
pwmchip_add_with_polarity() and move the code instead to pwmchip_add().
The initial assignment to pwm->state.polarity is dropped. In every correct
usage of the PWM API this value is overwritten later anyhow.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20201207134556.25217-4-uwe@kleine-koenig.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/core.c | 25 +++----------------------
include/linux/pwm.h | 2 --
2 files changed, 3 insertions(+), 24 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index a8eff4b3ee36..e7a2d9095669 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -260,18 +260,15 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
}
/**
- * pwmchip_add_with_polarity() - register a new PWM chip
+ * pwmchip_add() - register a new PWM chip
* @chip: the PWM chip to add
- * @polarity: initial polarity of PWM channels
*
* Register a new PWM chip. If chip->base < 0 then a dynamically assigned base
- * will be used. The initial polarity for all channels is specified by the
- * @polarity parameter.
+ * will be used.
*
* Returns: 0 on success or a negative error code on failure.
*/
-int pwmchip_add_with_polarity(struct pwm_chip *chip,
- enum pwm_polarity polarity)
+int pwmchip_add(struct pwm_chip *chip)
{
struct pwm_device *pwm;
unsigned int i;
@@ -303,7 +300,6 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
pwm->chip = chip;
pwm->pwm = chip->base + i;
pwm->hwpwm = i;
- pwm->state.polarity = polarity;
radix_tree_insert(&pwm_tree, pwm->pwm, pwm);
}
@@ -326,21 +322,6 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
return ret;
}
-EXPORT_SYMBOL_GPL(pwmchip_add_with_polarity);
-
-/**
- * pwmchip_add() - register a new PWM chip
- * @chip: the PWM chip to add
- *
- * Register a new PWM chip. If chip->base < 0 then a dynamically assigned base
- * will be used. The initial polarity for all channels is normal.
- *
- * Returns: 0 on success or a negative error code on failure.
- */
-int pwmchip_add(struct pwm_chip *chip)
-{
- return pwmchip_add_with_polarity(chip, PWM_POLARITY_NORMAL);
-}
EXPORT_SYMBOL_GPL(pwmchip_add);
/**
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index e4d84d4db293..8f4eefd129aa 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -392,8 +392,6 @@ int pwm_capture(struct pwm_device *pwm, struct pwm_capture *result,
int pwm_set_chip_data(struct pwm_device *pwm, void *data);
void *pwm_get_chip_data(struct pwm_device *pwm);
-int pwmchip_add_with_polarity(struct pwm_chip *chip,
- enum pwm_polarity polarity);
int pwmchip_add(struct pwm_chip *chip);
int pwmchip_remove(struct pwm_chip *chip);
struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 05/14] pwm: ab8500: Implement .apply instead of .config, .enable and .disable
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (3 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 04/14] pwm: Drop function pwmchip_add_with_polarity() Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 06/14] pwm: imx-tpm: Use a single line for error message Uwe Kleine-König
` (9 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel, Linus Walleij
To eventually get rid of all legacy drivers convert this driver to the
modern world implementing .apply().
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210301184537.1687926-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/pwm-ab8500.c | 53 +++++++++++++++++++---------------------
1 file changed, 25 insertions(+), 28 deletions(-)
diff --git a/drivers/pwm/pwm-ab8500.c b/drivers/pwm/pwm-ab8500.c
index 58c6c0f5b0ec..5b0a71243d0f 100644
--- a/drivers/pwm/pwm-ab8500.c
+++ b/drivers/pwm/pwm-ab8500.c
@@ -24,23 +24,37 @@ struct ab8500_pwm_chip {
struct pwm_chip chip;
};
-static int ab8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- int duty_ns, int period_ns)
+static int ab8500_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
{
- int ret = 0;
- unsigned int higher_val, lower_val;
+ int ret;
u8 reg;
+ unsigned int higher_val, lower_val;
+
+ if (state->polarity != PWM_POLARITY_NORMAL)
+ return -EINVAL;
+
+ if (!state->enabled) {
+ ret = abx500_mask_and_set_register_interruptible(chip->dev,
+ AB8500_MISC, AB8500_PWM_OUT_CTRL7_REG,
+ 1 << (chip->base - 1), 0);
+
+ if (ret < 0)
+ dev_err(chip->dev, "%s: Failed to disable PWM, Error %d\n",
+ pwm->label, ret);
+ return ret;
+ }
/*
* get the first 8 bits that are be written to
* AB8500_PWM_OUT_CTRL1_REG[0:7]
*/
- lower_val = duty_ns & 0x00FF;
+ lower_val = state->duty_cycle & 0x00FF;
/*
* get bits [9:10] that are to be written to
* AB8500_PWM_OUT_CTRL2_REG[0:1]
*/
- higher_val = ((duty_ns & 0x0300) >> 8);
+ higher_val = ((state->duty_cycle & 0x0300) >> 8);
reg = AB8500_PWM_OUT_CTRL1_REG + ((chip->base - 1) * 2);
@@ -48,15 +62,11 @@ static int ab8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
reg, (u8)lower_val);
if (ret < 0)
return ret;
+
ret = abx500_set_register_interruptible(chip->dev, AB8500_MISC,
(reg + 1), (u8)higher_val);
-
- return ret;
-}
-
-static int ab8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- int ret;
+ if (ret < 0)
+ return ret;
ret = abx500_mask_and_set_register_interruptible(chip->dev,
AB8500_MISC, AB8500_PWM_OUT_CTRL7_REG,
@@ -64,25 +74,12 @@ static int ab8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
if (ret < 0)
dev_err(chip->dev, "%s: Failed to enable PWM, Error %d\n",
pwm->label, ret);
- return ret;
-}
-static void ab8500_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- int ret;
-
- ret = abx500_mask_and_set_register_interruptible(chip->dev,
- AB8500_MISC, AB8500_PWM_OUT_CTRL7_REG,
- 1 << (chip->base - 1), 0);
- if (ret < 0)
- dev_err(chip->dev, "%s: Failed to disable PWM, Error %d\n",
- pwm->label, ret);
+ return ret;
}
static const struct pwm_ops ab8500_pwm_ops = {
- .config = ab8500_pwm_config,
- .enable = ab8500_pwm_enable,
- .disable = ab8500_pwm_disable,
+ .apply = ab8500_pwm_apply,
.owner = THIS_MODULE,
};
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 06/14] pwm: imx-tpm: Use a single line for error message
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (4 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 05/14] pwm: ab8500: Implement .apply instead of .config, .enable and .disable Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 07/14] pwm: Always allocate pwm id dynamically Uwe Kleine-König
` (8 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel, Fabio Estevam
From: Fabio Estevam <festevam@gmail.com>
There is no need to split the dev_err() call in three lines.
Use a single line to improve readability.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20210304024242.2363294-1-festevam@gmail.com
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/pwm-imx-tpm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
index aaf629bd8c35..eec9ec4e1a2a 100644
--- a/drivers/pwm/pwm-imx-tpm.c
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -411,9 +411,7 @@ static int __maybe_unused pwm_imx_tpm_resume(struct device *dev)
ret = clk_prepare_enable(tpm->clk);
if (ret)
- dev_err(dev,
- "failed to prepare or enable clock: %d\n",
- ret);
+ dev_err(dev, "failed to prepare or enable clock: %d\n", ret);
return ret;
}
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 07/14] pwm: Always allocate pwm id dynamically
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (5 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 06/14] pwm: imx-tpm: Use a single line for error message Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 08/14] pwm: Return -EINVAL for old-style drivers without .set_polarity callback Uwe Kleine-König
` (7 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel
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 ids and drop all assignments in the low-level drivers.
Link: https://lore.kernel.org/r/20210301185719.1689526-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/core.c | 23 ++++++-----------------
drivers/pwm/pwm-ab8500.c | 1 -
drivers/pwm/pwm-atmel-hlcdc.c | 1 -
drivers/pwm/pwm-atmel-tcb.c | 1 -
drivers/pwm/pwm-atmel.c | 1 -
drivers/pwm/pwm-bcm-iproc.c | 1 -
drivers/pwm/pwm-bcm-kona.c | 1 -
drivers/pwm/pwm-bcm2835.c | 1 -
drivers/pwm/pwm-berlin.c | 1 -
drivers/pwm/pwm-brcmstb.c | 1 -
drivers/pwm/pwm-clps711x.c | 1 -
drivers/pwm/pwm-crc.c | 1 -
drivers/pwm/pwm-cros-ec.c | 1 -
drivers/pwm/pwm-dwc.c | 1 -
drivers/pwm/pwm-ep93xx.c | 1 -
drivers/pwm/pwm-fsl-ftm.c | 1 -
drivers/pwm/pwm-hibvt.c | 1 -
drivers/pwm/pwm-img.c | 1 -
drivers/pwm/pwm-imx-tpm.c | 1 -
drivers/pwm/pwm-imx1.c | 1 -
drivers/pwm/pwm-imx27.c | 1 -
drivers/pwm/pwm-intel-lgm.c | 1 -
drivers/pwm/pwm-iqs620a.c | 1 -
drivers/pwm/pwm-jz4740.c | 1 -
drivers/pwm/pwm-keembay.c | 1 -
drivers/pwm/pwm-lp3943.c | 1 -
drivers/pwm/pwm-lpc18xx-sct.c | 1 -
drivers/pwm/pwm-lpc32xx.c | 1 -
drivers/pwm/pwm-lpss.c | 1 -
drivers/pwm/pwm-mediatek.c | 1 -
drivers/pwm/pwm-meson.c | 1 -
drivers/pwm/pwm-mtk-disp.c | 1 -
drivers/pwm/pwm-mxs.c | 1 -
drivers/pwm/pwm-omap-dmtimer.c | 1 -
drivers/pwm/pwm-pca9685.c | 1 -
drivers/pwm/pwm-pxa.c | 1 -
drivers/pwm/pwm-rcar.c | 1 -
drivers/pwm/pwm-renesas-tpu.c | 1 -
drivers/pwm/pwm-rockchip.c | 1 -
drivers/pwm/pwm-samsung.c | 1 -
drivers/pwm/pwm-sifive.c | 1 -
drivers/pwm/pwm-sl28cpld.c | 1 -
drivers/pwm/pwm-spear.c | 1 -
drivers/pwm/pwm-sprd.c | 1 -
drivers/pwm/pwm-sti.c | 1 -
drivers/pwm/pwm-stm32-lp.c | 1 -
drivers/pwm/pwm-stm32.c | 1 -
drivers/pwm/pwm-stmpe.c | 1 -
drivers/pwm/pwm-sun4i.c | 1 -
drivers/pwm/pwm-tegra.c | 1 -
drivers/pwm/pwm-tiecap.c | 1 -
drivers/pwm/pwm-tiehrpwm.c | 1 -
drivers/pwm/pwm-twl-led.c | 1 -
drivers/pwm/pwm-twl.c | 1 -
drivers/pwm/pwm-vt8500.c | 1 -
55 files changed, 6 insertions(+), 71 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index e7a2d9095669..9a2e739f2020 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -37,23 +37,13 @@ static struct pwm_device *pwm_to_device(unsigned int pwm)
return radix_tree_lookup(&pwm_tree, pwm);
}
-static int alloc_pwms(int pwm, unsigned int count)
+static int alloc_pwms(unsigned int count)
{
- unsigned int from = 0;
unsigned int start;
- if (pwm >= MAX_PWMS)
- return -EINVAL;
-
- if (pwm >= 0)
- from = pwm;
-
- start = bitmap_find_next_zero_area(allocated_pwms, MAX_PWMS, from,
+ start = bitmap_find_next_zero_area(allocated_pwms, MAX_PWMS, 0,
count, 0);
- if (pwm >= 0 && start != pwm)
- return -EEXIST;
-
if (start + count > MAX_PWMS)
return -ENOSPC;
@@ -263,8 +253,7 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
* pwmchip_add() - register a new PWM chip
* @chip: the PWM chip to add
*
- * Register a new PWM chip. If chip->base < 0 then a dynamically assigned base
- * will be used.
+ * Register a new PWM chip.
*
* Returns: 0 on success or a negative error code on failure.
*/
@@ -282,18 +271,18 @@ int pwmchip_add(struct pwm_chip *chip)
mutex_lock(&pwm_lock);
- ret = alloc_pwms(chip->base, chip->npwm);
+ ret = alloc_pwms(chip->npwm);
if (ret < 0)
goto out;
+ chip->base = ret;
+
chip->pwms = kcalloc(chip->npwm, sizeof(*pwm), GFP_KERNEL);
if (!chip->pwms) {
ret = -ENOMEM;
goto out;
}
- chip->base = ret;
-
for (i = 0; i < chip->npwm; i++) {
pwm = &chip->pwms[i];
diff --git a/drivers/pwm/pwm-ab8500.c b/drivers/pwm/pwm-ab8500.c
index 5b0a71243d0f..e2a26d9da25b 100644
--- a/drivers/pwm/pwm-ab8500.c
+++ b/drivers/pwm/pwm-ab8500.c
@@ -98,7 +98,6 @@ static int ab8500_pwm_probe(struct platform_device *pdev)
ab8500->chip.dev = &pdev->dev;
ab8500->chip.ops = &ab8500_pwm_ops;
- ab8500->chip.base = -1;
ab8500->chip.npwm = 1;
err = pwmchip_add(&ab8500->chip);
diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
index 4551aa2c484c..6ab597e54005 100644
--- a/drivers/pwm/pwm-atmel-hlcdc.c
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -265,7 +265,6 @@ static int atmel_hlcdc_pwm_probe(struct platform_device *pdev)
chip->hlcdc = hlcdc;
chip->chip.ops = &atmel_hlcdc_pwm_ops;
chip->chip.dev = dev;
- chip->chip.base = -1;
chip->chip.npwm = 1;
chip->chip.of_xlate = of_pwm_xlate_with_flags;
chip->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
index 5ccc3e7420e9..ee70a615532b 100644
--- a/drivers/pwm/pwm-atmel-tcb.c
+++ b/drivers/pwm/pwm-atmel-tcb.c
@@ -454,7 +454,6 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
tcbpwm->chip.ops = &atmel_tcb_pwm_ops;
tcbpwm->chip.of_xlate = of_pwm_xlate_with_flags;
tcbpwm->chip.of_pwm_n_cells = 3;
- tcbpwm->chip.base = -1;
tcbpwm->chip.npwm = NPWM;
tcbpwm->channel = channel;
tcbpwm->regmap = regmap;
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 5813339b597b..a4d0be6b265b 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -429,7 +429,6 @@ static int atmel_pwm_probe(struct platform_device *pdev)
atmel_pwm->chip.ops = &atmel_pwm_ops;
atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
atmel_pwm->chip.of_pwm_n_cells = 3;
- atmel_pwm->chip.base = -1;
atmel_pwm->chip.npwm = 4;
ret = pwmchip_add(&atmel_pwm->chip);
diff --git a/drivers/pwm/pwm-bcm-iproc.c b/drivers/pwm/pwm-bcm-iproc.c
index f4853c4a2d75..529a66ab692d 100644
--- a/drivers/pwm/pwm-bcm-iproc.c
+++ b/drivers/pwm/pwm-bcm-iproc.c
@@ -209,7 +209,6 @@ static int iproc_pwmc_probe(struct platform_device *pdev)
ip->chip.dev = &pdev->dev;
ip->chip.ops = &iproc_pwm_ops;
- ip->chip.base = -1;
ip->chip.npwm = 4;
ip->chip.of_xlate = of_pwm_xlate_with_flags;
ip->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
index 717b55677573..f09a31042859 100644
--- a/drivers/pwm/pwm-bcm-kona.c
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -271,7 +271,6 @@ static int kona_pwmc_probe(struct platform_device *pdev)
kp->chip.dev = &pdev->dev;
kp->chip.ops = &kona_pwm_ops;
- kp->chip.base = -1;
kp->chip.npwm = 6;
kp->chip.of_xlate = of_pwm_xlate_with_flags;
kp->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index d593cce249d9..e4b54675b356 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -158,7 +158,6 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
pc->chip.dev = &pdev->dev;
pc->chip.ops = &bcm2835_pwm_ops;
- pc->chip.base = -1;
pc->chip.npwm = 2;
pc->chip.of_xlate = of_pwm_xlate_with_flags;
pc->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-berlin.c b/drivers/pwm/pwm-berlin.c
index fe405289e582..acb6fbc3cc32 100644
--- a/drivers/pwm/pwm-berlin.c
+++ b/drivers/pwm/pwm-berlin.c
@@ -206,7 +206,6 @@ static int berlin_pwm_probe(struct platform_device *pdev)
pwm->chip.dev = &pdev->dev;
pwm->chip.ops = &berlin_pwm_ops;
- pwm->chip.base = -1;
pwm->chip.npwm = 4;
pwm->chip.of_xlate = of_pwm_xlate_with_flags;
pwm->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-brcmstb.c b/drivers/pwm/pwm-brcmstb.c
index 8b66f9d2f589..8b1d1e7aa856 100644
--- a/drivers/pwm/pwm-brcmstb.c
+++ b/drivers/pwm/pwm-brcmstb.c
@@ -258,7 +258,6 @@ static int brcmstb_pwm_probe(struct platform_device *pdev)
p->chip.dev = &pdev->dev;
p->chip.ops = &brcmstb_pwm_ops;
- p->chip.base = -1;
p->chip.npwm = 2;
p->base = devm_platform_ioremap_resource(pdev, 0);
diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
index cb1af86873ee..f3d17a590305 100644
--- a/drivers/pwm/pwm-clps711x.c
+++ b/drivers/pwm/pwm-clps711x.c
@@ -128,7 +128,6 @@ static int clps711x_pwm_probe(struct platform_device *pdev)
priv->chip.ops = &clps711x_pwm_ops;
priv->chip.dev = &pdev->dev;
- priv->chip.base = -1;
priv->chip.npwm = 2;
priv->chip.of_xlate = clps711x_pwm_xlate;
priv->chip.of_pwm_n_cells = 1;
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 1e2276808b7a..02522a9a3073 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -168,7 +168,6 @@ static int crystalcove_pwm_probe(struct platform_device *pdev)
pwm->chip.dev = &pdev->dev;
pwm->chip.ops = &crc_pwm_ops;
- pwm->chip.base = -1;
pwm->chip.npwm = 1;
/* get the PMIC regmap */
diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c
index c1c337969e4e..d3115cb0e058 100644
--- a/drivers/pwm/pwm-cros-ec.c
+++ b/drivers/pwm/pwm-cros-ec.c
@@ -253,7 +253,6 @@ static int cros_ec_pwm_probe(struct platform_device *pdev)
chip->ops = &cros_ec_pwm_ops;
chip->of_xlate = cros_ec_pwm_xlate;
chip->of_pwm_n_cells = 1;
- chip->base = -1;
ret = cros_ec_num_pwms(ec);
if (ret < 0) {
dev_err(dev, "Couldn't find PWMs: %d\n", ret);
diff --git a/drivers/pwm/pwm-dwc.c b/drivers/pwm/pwm-dwc.c
index f6c98e0d57c2..7568300bb11e 100644
--- a/drivers/pwm/pwm-dwc.c
+++ b/drivers/pwm/pwm-dwc.c
@@ -233,7 +233,6 @@ static int dwc_pwm_probe(struct pci_dev *pci, const struct pci_device_id *id)
dwc->chip.dev = dev;
dwc->chip.ops = &dwc_pwm_ops;
dwc->chip.npwm = DWC_TIMERS_TOTAL;
- dwc->chip.base = -1;
ret = pwmchip_add(&dwc->chip);
if (ret)
diff --git a/drivers/pwm/pwm-ep93xx.c b/drivers/pwm/pwm-ep93xx.c
index c9fc6f223640..4ca70794ad96 100644
--- a/drivers/pwm/pwm-ep93xx.c
+++ b/drivers/pwm/pwm-ep93xx.c
@@ -185,7 +185,6 @@ static int ep93xx_pwm_probe(struct platform_device *pdev)
ep93xx_pwm->chip.dev = &pdev->dev;
ep93xx_pwm->chip.ops = &ep93xx_pwm_ops;
- ep93xx_pwm->chip.base = -1;
ep93xx_pwm->chip.npwm = 1;
ret = pwmchip_add(&ep93xx_pwm->chip);
diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
index 2a6801226aba..0e1ae9469eda 100644
--- a/drivers/pwm/pwm-fsl-ftm.c
+++ b/drivers/pwm/pwm-fsl-ftm.c
@@ -453,7 +453,6 @@ static int fsl_pwm_probe(struct platform_device *pdev)
fpc->chip.ops = &fsl_pwm_ops;
fpc->chip.of_xlate = of_pwm_xlate_with_flags;
fpc->chip.of_pwm_n_cells = 3;
- fpc->chip.base = -1;
fpc->chip.npwm = 8;
ret = pwmchip_add(&fpc->chip);
diff --git a/drivers/pwm/pwm-hibvt.c b/drivers/pwm/pwm-hibvt.c
index a1900d0a872e..82d17fc75c21 100644
--- a/drivers/pwm/pwm-hibvt.c
+++ b/drivers/pwm/pwm-hibvt.c
@@ -205,7 +205,6 @@ static int hibvt_pwm_probe(struct platform_device *pdev)
pwm_chip->chip.ops = &hibvt_pwm_ops;
pwm_chip->chip.dev = &pdev->dev;
- pwm_chip->chip.base = -1;
pwm_chip->chip.npwm = soc->num_pwms;
pwm_chip->chip.of_xlate = of_pwm_xlate_with_flags;
pwm_chip->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-img.c b/drivers/pwm/pwm-img.c
index 6faf5b5a5584..cc37054589cc 100644
--- a/drivers/pwm/pwm-img.c
+++ b/drivers/pwm/pwm-img.c
@@ -304,7 +304,6 @@ static int img_pwm_probe(struct platform_device *pdev)
pwm->chip.dev = &pdev->dev;
pwm->chip.ops = &img_pwm_ops;
- pwm->chip.base = -1;
pwm->chip.npwm = IMG_PWM_NPWM;
ret = pwmchip_add(&pwm->chip);
diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
index eec9ec4e1a2a..97c9133b6876 100644
--- a/drivers/pwm/pwm-imx-tpm.c
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -363,7 +363,6 @@ static int pwm_imx_tpm_probe(struct platform_device *pdev)
tpm->chip.dev = &pdev->dev;
tpm->chip.ops = &imx_tpm_pwm_ops;
- tpm->chip.base = -1;
tpm->chip.of_xlate = of_pwm_xlate_with_flags;
tpm->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-imx1.c b/drivers/pwm/pwm-imx1.c
index 727e0d3e249e..c957b365448e 100644
--- a/drivers/pwm/pwm-imx1.c
+++ b/drivers/pwm/pwm-imx1.c
@@ -155,7 +155,6 @@ static int pwm_imx1_probe(struct platform_device *pdev)
imx->chip.ops = &pwm_imx1_ops;
imx->chip.dev = &pdev->dev;
- imx->chip.base = -1;
imx->chip.npwm = 1;
imx->mmio_base = devm_platform_ioremap_resource(pdev, 0);
diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 18055326a2f3..ba695115c160 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -327,7 +327,6 @@ static int pwm_imx27_probe(struct platform_device *pdev)
imx->chip.ops = &pwm_imx27_ops;
imx->chip.dev = &pdev->dev;
- imx->chip.base = -1;
imx->chip.npwm = 1;
imx->chip.of_xlate = of_pwm_xlate_with_flags;
diff --git a/drivers/pwm/pwm-intel-lgm.c b/drivers/pwm/pwm-intel-lgm.c
index e9e54dda07aa..015f5eba09a1 100644
--- a/drivers/pwm/pwm-intel-lgm.c
+++ b/drivers/pwm/pwm-intel-lgm.c
@@ -207,7 +207,6 @@ static int lgm_pwm_probe(struct platform_device *pdev)
pc->chip.dev = dev;
pc->chip.ops = &lgm_pwm_ops;
pc->chip.npwm = 1;
- pc->chip.base = -1;
lgm_pwm_init(pc);
diff --git a/drivers/pwm/pwm-iqs620a.c b/drivers/pwm/pwm-iqs620a.c
index 957b972c458b..6c6e26d18329 100644
--- a/drivers/pwm/pwm-iqs620a.c
+++ b/drivers/pwm/pwm-iqs620a.c
@@ -206,7 +206,6 @@ static int iqs620_pwm_probe(struct platform_device *pdev)
iqs620_pwm->chip.dev = &pdev->dev;
iqs620_pwm->chip.ops = &iqs620_pwm_ops;
- iqs620_pwm->chip.base = -1;
iqs620_pwm->chip.npwm = 1;
mutex_init(&iqs620_pwm->lock);
diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index 00c642fa2eed..5b6bdcdcecf5 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -244,7 +244,6 @@ static int jz4740_pwm_probe(struct platform_device *pdev)
jz4740->chip.dev = dev;
jz4740->chip.ops = &jz4740_pwm_ops;
jz4740->chip.npwm = info->num_pwms;
- jz4740->chip.base = -1;
jz4740->chip.of_xlate = of_pwm_xlate_with_flags;
jz4740->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-keembay.c b/drivers/pwm/pwm-keembay.c
index cdfdef66ff8e..521a825c8ba0 100644
--- a/drivers/pwm/pwm-keembay.c
+++ b/drivers/pwm/pwm-keembay.c
@@ -203,7 +203,6 @@ static int keembay_pwm_probe(struct platform_device *pdev)
if (ret)
return ret;
- priv->chip.base = -1;
priv->chip.dev = dev;
priv->chip.ops = &keembay_pwm_ops;
priv->chip.npwm = KMB_TOTAL_PWM_CHANNELS;
diff --git a/drivers/pwm/pwm-lp3943.c b/drivers/pwm/pwm-lp3943.c
index bf3f14fb5f24..7551253ada32 100644
--- a/drivers/pwm/pwm-lp3943.c
+++ b/drivers/pwm/pwm-lp3943.c
@@ -275,7 +275,6 @@ static int lp3943_pwm_probe(struct platform_device *pdev)
lp3943_pwm->chip.dev = &pdev->dev;
lp3943_pwm->chip.ops = &lp3943_pwm_ops;
lp3943_pwm->chip.npwm = LP3943_NUM_PWMS;
- lp3943_pwm->chip.base = -1;
platform_set_drvdata(pdev, lp3943_pwm);
diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
index 7ef40243eb6c..3f8e54ec28c6 100644
--- a/drivers/pwm/pwm-lpc18xx-sct.c
+++ b/drivers/pwm/pwm-lpc18xx-sct.c
@@ -370,7 +370,6 @@ static int lpc18xx_pwm_probe(struct platform_device *pdev)
lpc18xx_pwm->chip.dev = &pdev->dev;
lpc18xx_pwm->chip.ops = &lpc18xx_pwm_ops;
- lpc18xx_pwm->chip.base = -1;
lpc18xx_pwm->chip.npwm = 16;
lpc18xx_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
lpc18xx_pwm->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-lpc32xx.c b/drivers/pwm/pwm-lpc32xx.c
index 6b4090436c06..c42cc314c170 100644
--- a/drivers/pwm/pwm-lpc32xx.c
+++ b/drivers/pwm/pwm-lpc32xx.c
@@ -116,7 +116,6 @@ static int lpc32xx_pwm_probe(struct platform_device *pdev)
lpc32xx->chip.dev = &pdev->dev;
lpc32xx->chip.ops = &lpc32xx_pwm_ops;
lpc32xx->chip.npwm = 1;
- lpc32xx->chip.base = -1;
ret = pwmchip_add(&lpc32xx->chip);
if (ret < 0) {
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 939de93c157b..9ea6a176cbe5 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -234,7 +234,6 @@ struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, struct resource *r,
lpwm->chip.dev = dev;
lpwm->chip.ops = &pwm_lpss_ops;
- lpwm->chip.base = -1;
lpwm->chip.npwm = info->npwm;
ret = pwmchip_add(&lpwm->chip);
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index fcfc3b147e5f..87fb37d43814 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -263,7 +263,6 @@ static int pwm_mediatek_probe(struct platform_device *pdev)
pc->chip.dev = &pdev->dev;
pc->chip.ops = &pwm_mediatek_ops;
- pc->chip.base = -1;
pc->chip.npwm = pc->soc->num_pwms;
ret = pwmchip_add(&pc->chip);
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index a3ce9789412a..9eb060613cb4 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -550,7 +550,6 @@ static int meson_pwm_probe(struct platform_device *pdev)
spin_lock_init(&meson->lock);
meson->chip.dev = &pdev->dev;
meson->chip.ops = &meson_pwm_ops;
- meson->chip.base = -1;
meson->chip.npwm = MESON_NUM_PWMS;
meson->chip.of_xlate = of_pwm_xlate_with_flags;
meson->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 87c6b4bc5d43..9b3ba401a3db 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -202,7 +202,6 @@ static int mtk_disp_pwm_probe(struct platform_device *pdev)
mdp->chip.dev = &pdev->dev;
mdp->chip.ops = &mtk_disp_pwm_ops;
- mdp->chip.base = -1;
mdp->chip.npwm = 1;
ret = pwmchip_add(&mdp->chip);
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
index 7ce616923c52..0266e84e982c 100644
--- a/drivers/pwm/pwm-mxs.c
+++ b/drivers/pwm/pwm-mxs.c
@@ -140,7 +140,6 @@ static int mxs_pwm_probe(struct platform_device *pdev)
mxs->chip.ops = &mxs_pwm_ops;
mxs->chip.of_xlate = of_pwm_xlate_with_flags;
mxs->chip.of_pwm_n_cells = 3;
- mxs->chip.base = -1;
ret = of_property_read_u32(np, "fsl,pwm-number", &mxs->chip.npwm);
if (ret < 0) {
diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 358db4ff9d4f..612b3c859295 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -403,7 +403,6 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
omap->chip.dev = &pdev->dev;
omap->chip.ops = &pwm_omap_dmtimer_ops;
- omap->chip.base = -1;
omap->chip.npwm = 1;
omap->chip.of_xlate = of_pwm_xlate_with_flags;
omap->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
index 4a55dc18656c..00976b2c57b2 100644
--- a/drivers/pwm/pwm-pca9685.c
+++ b/drivers/pwm/pwm-pca9685.c
@@ -493,7 +493,6 @@ static int pca9685_pwm_probe(struct i2c_client *client,
pca->chip.npwm = PCA9685_MAXCHAN + 1;
pca->chip.dev = &client->dev;
- pca->chip.base = -1;
ret = pwmchip_add(&pca->chip);
if (ret < 0)
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index d06cf60e6575..cfb683827d32 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -184,7 +184,6 @@ static int pwm_probe(struct platform_device *pdev)
pwm->chip.dev = &pdev->dev;
pwm->chip.ops = &pxa_pwm_ops;
- pwm->chip.base = -1;
pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
if (IS_ENABLED(CONFIG_OF)) {
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index 002ab79a7ec2..9daca0c772c7 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -224,7 +224,6 @@ static int rcar_pwm_probe(struct platform_device *pdev)
rcar_pwm->chip.dev = &pdev->dev;
rcar_pwm->chip.ops = &rcar_pwm_ops;
- rcar_pwm->chip.base = -1;
rcar_pwm->chip.npwm = 1;
pm_runtime_enable(&pdev->dev);
diff --git a/drivers/pwm/pwm-renesas-tpu.c b/drivers/pwm/pwm-renesas-tpu.c
index d02b24b77cdf..e2959fae0969 100644
--- a/drivers/pwm/pwm-renesas-tpu.c
+++ b/drivers/pwm/pwm-renesas-tpu.c
@@ -410,7 +410,6 @@ static int tpu_probe(struct platform_device *pdev)
tpu->chip.ops = &tpu_pwm_ops;
tpu->chip.of_xlate = of_pwm_xlate_with_flags;
tpu->chip.of_pwm_n_cells = 3;
- tpu->chip.base = -1;
tpu->chip.npwm = TPU_CHANNEL_MAX;
pm_runtime_enable(&pdev->dev);
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 6ad7d0a50aed..301785fa293e 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -352,7 +352,6 @@ static int rockchip_pwm_probe(struct platform_device *pdev)
pc->data = id->data;
pc->chip.dev = &pdev->dev;
pc->chip.ops = &rockchip_pwm_ops;
- pc->chip.base = -1;
pc->chip.npwm = 1;
if (pc->data->supports_polarity) {
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index 645d0066ff0a..515489fa4f6d 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -519,7 +519,6 @@ static int pwm_samsung_probe(struct platform_device *pdev)
chip->chip.dev = &pdev->dev;
chip->chip.ops = &pwm_samsung_ops;
- chip->chip.base = -1;
chip->chip.npwm = SAMSUNG_PWM_NUM;
chip->inverter_mask = BIT(SAMSUNG_PWM_NUM) - 1;
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index 2a7cd2deaeea..688737f091ac 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -244,7 +244,6 @@ static int pwm_sifive_probe(struct platform_device *pdev)
chip->ops = &pwm_sifive_ops;
chip->of_xlate = of_pwm_xlate_with_flags;
chip->of_pwm_n_cells = 3;
- chip->base = -1;
chip->npwm = 4;
ddata->regs = devm_platform_ioremap_resource(pdev, 0);
diff --git a/drivers/pwm/pwm-sl28cpld.c b/drivers/pwm/pwm-sl28cpld.c
index 0b01ec25e2f0..7a69c1a0c060 100644
--- a/drivers/pwm/pwm-sl28cpld.c
+++ b/drivers/pwm/pwm-sl28cpld.c
@@ -229,7 +229,6 @@ static int sl28cpld_pwm_probe(struct platform_device *pdev)
chip = &priv->pwm_chip;
chip->dev = &pdev->dev;
chip->ops = &sl28cpld_pwm_ops;
- chip->base = -1;
chip->npwm = 1;
platform_set_drvdata(pdev, priv);
diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
index f63b54aae1b4..1a1cedfd11ce 100644
--- a/drivers/pwm/pwm-spear.c
+++ b/drivers/pwm/pwm-spear.c
@@ -193,7 +193,6 @@ static int spear_pwm_probe(struct platform_device *pdev)
pc->chip.dev = &pdev->dev;
pc->chip.ops = &spear_pwm_ops;
- pc->chip.base = -1;
pc->chip.npwm = NUM_PWM;
ret = clk_prepare(pc->clk);
diff --git a/drivers/pwm/pwm-sprd.c b/drivers/pwm/pwm-sprd.c
index 5123d948efd6..108cbec88667 100644
--- a/drivers/pwm/pwm-sprd.c
+++ b/drivers/pwm/pwm-sprd.c
@@ -268,7 +268,6 @@ static int sprd_pwm_probe(struct platform_device *pdev)
spc->chip.dev = &pdev->dev;
spc->chip.ops = &sprd_pwm_ops;
- spc->chip.base = -1;
spc->chip.npwm = spc->num_pwms;
ret = pwmchip_add(&spc->chip);
diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 99c70e07858d..aa2b211d7ee3 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -619,7 +619,6 @@ static int sti_pwm_probe(struct platform_device *pdev)
pc->chip.dev = dev;
pc->chip.ops = &sti_pwm_ops;
- pc->chip.base = -1;
pc->chip.npwm = pc->cdata->pwm_num_devs;
ret = pwmchip_add(&pc->chip);
diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 134c14621ee0..af08f564ef1d 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -205,7 +205,6 @@ static int stm32_pwm_lp_probe(struct platform_device *pdev)
priv->regmap = ddata->regmap;
priv->clk = ddata->clk;
- priv->chip.base = -1;
priv->chip.dev = &pdev->dev;
priv->chip.ops = &stm32_pwm_lp_ops;
priv->chip.npwm = 1;
diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index d3be944f2ae9..c46fb90036ab 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -633,7 +633,6 @@ static int stm32_pwm_probe(struct platform_device *pdev)
stm32_pwm_detect_complementary(priv);
- priv->chip.base = -1;
priv->chip.dev = dev;
priv->chip.ops = &stm32pwm_ops;
priv->chip.npwm = stm32_pwm_detect_channels(priv);
diff --git a/drivers/pwm/pwm-stmpe.c b/drivers/pwm/pwm-stmpe.c
index be5f6d7359d4..9dc983a3cbf1 100644
--- a/drivers/pwm/pwm-stmpe.c
+++ b/drivers/pwm/pwm-stmpe.c
@@ -278,7 +278,6 @@ static int __init stmpe_pwm_probe(struct platform_device *pdev)
pwm->stmpe = stmpe;
pwm->chip.dev = &pdev->dev;
- pwm->chip.base = -1;
if (stmpe->partnum == STMPE2401 || stmpe->partnum == STMPE2403) {
pwm->chip.ops = &stmpe_24xx_pwm_ops;
diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index ce5c4fc8da6f..e01becd102c0 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -459,7 +459,6 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
pwm->chip.dev = &pdev->dev;
pwm->chip.ops = &sun4i_pwm_ops;
- pwm->chip.base = -1;
pwm->chip.npwm = pwm->data->npwm;
pwm->chip.of_xlate = of_pwm_xlate_with_flags;
pwm->chip.of_pwm_n_cells = 3;
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index 55bc63d5a0ae..c529a170bcdd 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -285,7 +285,6 @@ static int tegra_pwm_probe(struct platform_device *pdev)
pwm->chip.dev = &pdev->dev;
pwm->chip.ops = &tegra_pwm_ops;
- pwm->chip.base = -1;
pwm->chip.npwm = pwm->soc->num_channels;
ret = pwmchip_add(&pwm->chip);
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 2a8949014bb1..b9a17ab0c202 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -226,7 +226,6 @@ static int ecap_pwm_probe(struct platform_device *pdev)
pc->chip.ops = &ecap_pwm_ops;
pc->chip.of_xlate = of_pwm_xlate_with_flags;
pc->chip.of_pwm_n_cells = 3;
- pc->chip.base = -1;
pc->chip.npwm = 1;
pc->mmio_base = devm_platform_ioremap_resource(pdev, 0);
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index a7fb224d6535..90095a19bf2d 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -449,7 +449,6 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
pc->chip.ops = &ehrpwm_pwm_ops;
pc->chip.of_xlate = of_pwm_xlate_with_flags;
pc->chip.of_pwm_n_cells = 3;
- pc->chip.base = -1;
pc->chip.npwm = NUM_PWM_CHANNEL;
pc->mmio_base = devm_platform_ioremap_resource(pdev, 0);
diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
index 630b9a578820..6c8df5f4e87d 100644
--- a/drivers/pwm/pwm-twl-led.c
+++ b/drivers/pwm/pwm-twl-led.c
@@ -291,7 +291,6 @@ static int twl_pwmled_probe(struct platform_device *pdev)
}
twl->chip.dev = &pdev->dev;
- twl->chip.base = -1;
mutex_init(&twl->mutex);
diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c
index aee67974f353..e83a826bf621 100644
--- a/drivers/pwm/pwm-twl.c
+++ b/drivers/pwm/pwm-twl.c
@@ -310,7 +310,6 @@ static int twl_pwm_probe(struct platform_device *pdev)
twl->chip.ops = &twl6030_pwm_ops;
twl->chip.dev = &pdev->dev;
- twl->chip.base = -1;
twl->chip.npwm = 2;
mutex_init(&twl->mutex);
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index 6e36851a22bb..52fe5d19473a 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -209,7 +209,6 @@ static int vt8500_pwm_probe(struct platform_device *pdev)
chip->chip.ops = &vt8500_pwm_ops;
chip->chip.of_xlate = of_pwm_xlate_with_flags;
chip->chip.of_pwm_n_cells = 3;
- chip->chip.base = -1;
chip->chip.npwm = VT8500_NR_PWMS;
chip->clk = devm_clk_get(&pdev->dev, NULL);
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 08/14] pwm: Return -EINVAL for old-style drivers without .set_polarity callback
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (6 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 07/14] pwm: Always allocate pwm id dynamically Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 09/14] pwm: Prevent a glitch in compat code Uwe Kleine-König
` (6 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel
Since commit 2b1c1a5d5148 ("pwm: Use -EINVAL for unsupported polarity")
all drivers implementing the apply callback are unified to return
-EINVAL if an unsupported polarity is requested. Do the same in the
compat code for old-style drivers.
Link: https://lore.kernel.org/r/20210301182307.1681548-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 9a2e739f2020..c4d5c0667137 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -577,7 +577,7 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
*/
if (state->polarity != pwm->state.polarity) {
if (!chip->ops->set_polarity)
- return -ENOTSUPP;
+ return -EINVAL;
/*
* Changing the polarity of a running PWM is
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 09/14] pwm: Prevent a glitch in compat code
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (7 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 08/14] pwm: Return -EINVAL for old-style drivers without .set_polarity callback Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 10/14] pwm: atmel-tcb: Implement .apply callback Uwe Kleine-König
` (5 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel
When a PWM is to be disabled, configuring the duty cycle and
period before actually disabling the hardware might result in either a
glitch or a delay. So check for disabling first and return early in this
case.
Link: https://lore.kernel.org/r/20210308093600.25455-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/core.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index c4d5c0667137..4b3779d58c5a 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -597,6 +597,12 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
pwm->state.polarity = state->polarity;
}
+ if (!state->enabled && pwm->state.enabled) {
+ chip->ops->disable(chip, pwm);
+ pwm->state.enabled = false;
+ return 0;
+ }
+
if (state->period != pwm->state.period ||
state->duty_cycle != pwm->state.duty_cycle) {
err = chip->ops->config(pwm->chip, pwm,
@@ -609,16 +615,12 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
pwm->state.period = state->period;
}
- if (state->enabled != pwm->state.enabled) {
- if (state->enabled) {
- err = chip->ops->enable(chip, pwm);
- if (err)
- return err;
- } else {
- chip->ops->disable(chip, pwm);
- }
+ if (!pwm->state.enabled) {
+ err = chip->ops->enable(chip, pwm);
+ if (err)
+ return err;
- pwm->state.enabled = state->enabled;
+ pwm->state.enabled = true;
}
}
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 10/14] pwm: atmel-tcb: Implement .apply callback
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (8 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 09/14] pwm: Prevent a glitch in compat code Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 11/14] pwm: atmel-tcb: Only free resources after pwm_chip_remove() returned Uwe Kleine-König
` (4 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel
This is just pushing down the core's compat code down into the driver using
the legacy callback nearly unchanged. The call to .enable() was just
dropped from .config() because .apply() calls it unconditionally.
Link: https://lore.kernel.org/r/20210308095012.26529-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/pwm-atmel-tcb.c | 33 +++++++++++++++++++++++++--------
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
index ee70a615532b..4d2253f3048c 100644
--- a/drivers/pwm/pwm-atmel-tcb.c
+++ b/drivers/pwm/pwm-atmel-tcb.c
@@ -362,20 +362,37 @@ static int atmel_tcb_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
tcbpwm->div = i;
tcbpwm->duty = duty;
- /* If the PWM is enabled, call enable to apply the new conf */
- if (pwm_is_enabled(pwm))
- atmel_tcb_pwm_enable(chip, pwm);
-
return 0;
}
+static int atmel_tcb_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ int duty_cycle, period;
+ int ret;
+
+ /* This function only sets a flag in driver data */
+ atmel_tcb_pwm_set_polarity(chip, pwm, state->polarity);
+
+ if (!state->enabled) {
+ atmel_tcb_pwm_disable(chip, pwm);
+ return 0;
+ }
+
+ period = state->period < INT_MAX ? state->period : INT_MAX;
+ duty_cycle = state->duty_cycle < INT_MAX ? state->duty_cycle : INT_MAX;
+
+ ret = atmel_tcb_pwm_config(chip, pwm, duty_cycle, period);
+ if (ret)
+ return ret;
+
+ return atmel_tcb_pwm_enable(chip, pwm);
+}
+
static const struct pwm_ops atmel_tcb_pwm_ops = {
.request = atmel_tcb_pwm_request,
.free = atmel_tcb_pwm_free,
- .config = atmel_tcb_pwm_config,
- .set_polarity = atmel_tcb_pwm_set_polarity,
- .enable = atmel_tcb_pwm_enable,
- .disable = atmel_tcb_pwm_disable,
+ .apply = atmel_tcb_pwm_apply,
.owner = THIS_MODULE,
};
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 11/14] pwm: atmel-tcb: Only free resources after pwm_chip_remove() returned
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (9 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 10/14] pwm: atmel-tcb: Implement .apply callback Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 12/14] pwm: sprd: Refuse requests with unsupported polarity Uwe Kleine-König
` (3 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel
Otherwise the PWM stops working before the PWM core and its consumers
are aware the device is going away.
Link: https://lore.kernel.org/r/20210308095150.26774-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/pwm-atmel-tcb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
index 4d2253f3048c..8451d3e846be 100644
--- a/drivers/pwm/pwm-atmel-tcb.c
+++ b/drivers/pwm/pwm-atmel-tcb.c
@@ -507,14 +507,14 @@ static int atmel_tcb_pwm_remove(struct platform_device *pdev)
struct atmel_tcb_pwm_chip *tcbpwm = platform_get_drvdata(pdev);
int err;
- clk_disable_unprepare(tcbpwm->slow_clk);
- clk_put(tcbpwm->slow_clk);
- clk_put(tcbpwm->clk);
-
err = pwmchip_remove(&tcbpwm->chip);
if (err < 0)
return err;
+ clk_disable_unprepare(tcbpwm->slow_clk);
+ clk_put(tcbpwm->slow_clk);
+ clk_put(tcbpwm->clk);
+
return 0;
}
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 12/14] pwm: sprd: Refuse requests with unsupported polarity
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (10 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 11/14] pwm: atmel-tcb: Only free resources after pwm_chip_remove() returned Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 13/14] pwm: cros-ec: " Uwe Kleine-König
` (2 subsequent siblings)
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel, Chunyan Zhang
The driver only supports normal polarity and so should refuse requests
for inversed polarity.
Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
Link: https://lore.kernel.org/r/20210312085916.386422-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/pwm-sprd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pwm/pwm-sprd.c b/drivers/pwm/pwm-sprd.c
index 108cbec88667..98c479dfae31 100644
--- a/drivers/pwm/pwm-sprd.c
+++ b/drivers/pwm/pwm-sprd.c
@@ -164,6 +164,9 @@ static int sprd_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *cstate = &pwm->state;
int ret;
+ if (state->polarity != PWM_POLARITY_NORMAL)
+ return -EINVAL;
+
if (state->enabled) {
if (!cstate->enabled) {
/*
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 13/14] pwm: cros-ec: Refuse requests with unsupported polarity
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (11 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 12/14] pwm: sprd: Refuse requests with unsupported polarity Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 14/14] pwm: Soften potential loss of precision in compat code Uwe Kleine-König
2021-03-22 13:26 ` [PATCH 00/14] pwm: Patches I consider ready for the next merge window Thierry Reding
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel, Enric Balletbo i Serra
The driver only supports normal polarity and so should refuse requests
for inversed polarity.
Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20210312090058.386850-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/pwm-cros-ec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c
index d3115cb0e058..9fffb566af5f 100644
--- a/drivers/pwm/pwm-cros-ec.c
+++ b/drivers/pwm/pwm-cros-ec.c
@@ -124,6 +124,9 @@ static int cros_ec_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
if (state->period != EC_PWM_MAX_DUTY)
return -EINVAL;
+ if (state->polarity != PWM_POLARITY_NORMAL)
+ return -EINVAL;
+
/*
* EC doesn't separate the concept of duty cycle and enabled, but
* kernel does. Translate.
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* [PATCH 14/14] pwm: Soften potential loss of precision in compat code
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (12 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 13/14] pwm: cros-ec: " Uwe Kleine-König
@ 2021-03-19 10:28 ` Uwe Kleine-König
2021-03-22 13:26 ` [PATCH 00/14] pwm: Patches I consider ready for the next merge window Thierry Reding
14 siblings, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-19 10:28 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel, Guru Das Srinagesh
The legacy callback .config() only uses int for period and duty_cycle
while the corresponding values in struct pwm_state are u64. To prevent
that a value bigger than INT_MAX is discarded to a very small value,
explicitly check for big values and pass INT_MAX instead of discarding.
Acked-by: Guru Das Srinagesh <gurus@codeaurora.org>
Link: https://lore.kernel.org/r/20210315080050.2337075-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/pwm/core.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 4b3779d58c5a..b1adf3bb8508 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -605,9 +605,18 @@ int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state)
if (state->period != pwm->state.period ||
state->duty_cycle != pwm->state.duty_cycle) {
+ int duty_cycle, period;
+
+ /*
+ * The legacy callbacks use only (signed!) int for
+ * period and duty_cycle compared to u64 in struct
+ * pwm_state. So clamp the values to INT_MAX.
+ */
+ period = min(state->period, (u64)INT_MAX);
+ duty_cycle = min(state->duty_cycle, (u64)INT_MAX);
+
err = chip->ops->config(pwm->chip, pwm,
- state->duty_cycle,
- state->period);
+ duty_cycle, period);
if (err)
return err;
--
2.30.1
^ permalink raw reply related [flat|nested] 21+ messages in thread* Re: [PATCH 00/14] pwm: Patches I consider ready for the next merge window
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
` (13 preceding siblings ...)
2021-03-19 10:28 ` [PATCH 14/14] pwm: Soften potential loss of precision in compat code Uwe Kleine-König
@ 2021-03-22 13:26 ` Thierry Reding
2021-03-22 14:00 ` Uwe Kleine-König
2021-03-23 7:19 ` Lee Jones
14 siblings, 2 replies; 21+ messages in thread
From: Thierry Reding @ 2021-03-22 13:26 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Lee Jones, linux-pwm, kernel
[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]
On Fri, Mar 19, 2021 at 11:28:38AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> this is the set of patches that are open on the list for some time.
> Lee suggested to resend them.
>
> @Thierry: I'm unsure what is the best way to nag. Is it really
> resending? Or does this just result mostly in overhead because the
> patches are still open in patchwork and it adds copies to your mailbox?
> (Another downside is that taking the patches from this thread results in
> recording a newer Author Date compared to picking up the originals.)
I use patchwork extensively for tracking, so merely resending patches so
that they float to the top of my inbox isn't useful in itself. Patches
do, by the way, float to the top of my inbox when you just reply to them
(e.g. by pinging). Resending a particular series is fine because it's
then easy to mark the old version as "superseded". Sending a collection
of patch such as this is a bit more annoying because now the duplicates
are spread about a bit more in patchwork, so it's a bit more work to get
patchwork cleaned up. But it's not that bad, so no harm done.
Usually when I look at patchwork I will look at the A/F/R/T column and
the more flags I see there, the more likely I will be to go and apply
it. Anything else I will go and look at myself and comment and/or apply
or sometimes wait for someone else to review.
Perhaps a better way to nag me would be to delegate patches that you've
reviewed or think are ready to me, which would make them stand out more
among the others.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [PATCH 00/14] pwm: Patches I consider ready for the next merge window
2021-03-22 13:26 ` [PATCH 00/14] pwm: Patches I consider ready for the next merge window Thierry Reding
@ 2021-03-22 14:00 ` Uwe Kleine-König
2021-03-23 7:19 ` Lee Jones
1 sibling, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-03-22 14:00 UTC (permalink / raw)
To: Thierry Reding; +Cc: linux-pwm, Lee Jones, kernel
[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]
Hello Thierry,
On Mon, Mar 22, 2021 at 02:26:13PM +0100, Thierry Reding wrote:
> On Fri, Mar 19, 2021 at 11:28:38AM +0100, Uwe Kleine-König wrote:
> > this is the set of patches that are open on the list for some time.
> > Lee suggested to resend them.
> >
> > @Thierry: I'm unsure what is the best way to nag. Is it really
> > resending? Or does this just result mostly in overhead because the
> > patches are still open in patchwork and it adds copies to your mailbox?
> > (Another downside is that taking the patches from this thread results in
> > recording a newer Author Date compared to picking up the originals.)
>
> I use patchwork extensively for tracking, so merely resending patches so
> that they float to the top of my inbox isn't useful in itself. Patches
> do, by the way, float to the top of my inbox when you just reply to them
> (e.g. by pinging). Resending a particular series is fine because it's
> then easy to mark the old version as "superseded". Sending a collection
> of patch such as this is a bit more annoying because now the duplicates
> are spread about a bit more in patchwork, so it's a bit more work to get
> patchwork cleaned up. But it's not that bad, so no harm done.
>
> Usually when I look at patchwork I will look at the A/F/R/T column and
> the more flags I see there, the more likely I will be to go and apply
> it. Anything else I will go and look at myself and comment and/or apply
> or sometimes wait for someone else to review.
>
> Perhaps a better way to nag me would be to delegate patches that you've
> reviewed or think are ready to me, which would make them stand out more
> among the others.
ok, so my doubts were justified. I'll try the delegation idea next time
:-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 00/14] pwm: Patches I consider ready for the next merge window
2021-03-22 13:26 ` [PATCH 00/14] pwm: Patches I consider ready for the next merge window Thierry Reding
2021-03-22 14:00 ` Uwe Kleine-König
@ 2021-03-23 7:19 ` Lee Jones
2021-03-23 8:53 ` Thierry Reding
2021-04-08 10:43 ` Uwe Kleine-König
1 sibling, 2 replies; 21+ messages in thread
From: Lee Jones @ 2021-03-23 7:19 UTC (permalink / raw)
To: Thierry Reding; +Cc: Uwe Kleine-König, linux-pwm, kernel
On Mon, 22 Mar 2021, Thierry Reding wrote:
> On Fri, Mar 19, 2021 at 11:28:38AM +0100, Uwe Kleine-König wrote:
> > Hello,
> >
> > this is the set of patches that are open on the list for some time.
> > Lee suggested to resend them.
> >
> > @Thierry: I'm unsure what is the best way to nag. Is it really
> > resending? Or does this just result mostly in overhead because the
> > patches are still open in patchwork and it adds copies to your mailbox?
> > (Another downside is that taking the patches from this thread results in
> > recording a newer Author Date compared to picking up the originals.)
>
> I use patchwork extensively for tracking, so merely resending patches so
> that they float to the top of my inbox isn't useful in itself. Patches
> do, by the way, float to the top of my inbox when you just reply to them
> (e.g. by pinging). Resending a particular series is fine because it's
> then easy to mark the old version as "superseded". Sending a collection
> of patch such as this is a bit more annoying because now the duplicates
> are spread about a bit more in patchwork, so it's a bit more work to get
> patchwork cleaned up. But it's not that bad, so no harm done.
>
> Usually when I look at patchwork I will look at the A/F/R/T column and
> the more flags I see there, the more likely I will be to go and apply
> it. Anything else I will go and look at myself and comment and/or apply
> or sometimes wait for someone else to review.
>
> Perhaps a better way to nag me would be to delegate patches that you've
> reviewed or think are ready to me, which would make them stand out more
> among the others.
It's not Uwe's fault, it's mine.
Since some of Uwe's patches had been left unreviewed for several
weeks, I asked him to collect up all of his dangling patches and
submit this resend for *me* to review.
As someone who does not use Patchwork, I find this to be the simplest
and cleanest method of patch collation. Going by your almost
immediate reply, I guess it had a nice desired side-effect. :)
Thanks for taking the time.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 00/14] pwm: Patches I consider ready for the next merge window
2021-03-23 7:19 ` Lee Jones
@ 2021-03-23 8:53 ` Thierry Reding
2021-03-23 9:02 ` Lee Jones
2021-04-08 10:43 ` Uwe Kleine-König
1 sibling, 1 reply; 21+ messages in thread
From: Thierry Reding @ 2021-03-23 8:53 UTC (permalink / raw)
To: Lee Jones; +Cc: Uwe Kleine-König, linux-pwm, kernel
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
On Tue, Mar 23, 2021 at 07:19:29AM +0000, Lee Jones wrote:
> On Mon, 22 Mar 2021, Thierry Reding wrote:
>
> > On Fri, Mar 19, 2021 at 11:28:38AM +0100, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > this is the set of patches that are open on the list for some time.
> > > Lee suggested to resend them.
> > >
> > > @Thierry: I'm unsure what is the best way to nag. Is it really
> > > resending? Or does this just result mostly in overhead because the
> > > patches are still open in patchwork and it adds copies to your mailbox?
> > > (Another downside is that taking the patches from this thread results in
> > > recording a newer Author Date compared to picking up the originals.)
> >
> > I use patchwork extensively for tracking, so merely resending patches so
> > that they float to the top of my inbox isn't useful in itself. Patches
> > do, by the way, float to the top of my inbox when you just reply to them
> > (e.g. by pinging). Resending a particular series is fine because it's
> > then easy to mark the old version as "superseded". Sending a collection
> > of patch such as this is a bit more annoying because now the duplicates
> > are spread about a bit more in patchwork, so it's a bit more work to get
> > patchwork cleaned up. But it's not that bad, so no harm done.
> >
> > Usually when I look at patchwork I will look at the A/F/R/T column and
> > the more flags I see there, the more likely I will be to go and apply
> > it. Anything else I will go and look at myself and comment and/or apply
> > or sometimes wait for someone else to review.
> >
> > Perhaps a better way to nag me would be to delegate patches that you've
> > reviewed or think are ready to me, which would make them stand out more
> > among the others.
>
> It's not Uwe's fault, it's mine.
>
> Since some of Uwe's patches had been left unreviewed for several
> weeks, I asked him to collect up all of his dangling patches and
> submit this resend for *me* to review.
Like I said, it's not a big deal. And I'm also aware that this is misery
of my own making, so no worries.
> As someone who does not use Patchwork, I find this to be the simplest
> and cleanest method of patch collation. Going by your almost
> immediate reply, I guess it had a nice desired side-effect. :)
Indeed, it achieved the desired effect, so can't argue about its
effectiveness. =)
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 00/14] pwm: Patches I consider ready for the next merge window
2021-03-23 8:53 ` Thierry Reding
@ 2021-03-23 9:02 ` Lee Jones
0 siblings, 0 replies; 21+ messages in thread
From: Lee Jones @ 2021-03-23 9:02 UTC (permalink / raw)
To: Thierry Reding; +Cc: Uwe Kleine-König, linux-pwm, kernel
On Tue, 23 Mar 2021, Thierry Reding wrote:
> On Tue, Mar 23, 2021 at 07:19:29AM +0000, Lee Jones wrote:
> > On Mon, 22 Mar 2021, Thierry Reding wrote:
> >
> > > On Fri, Mar 19, 2021 at 11:28:38AM +0100, Uwe Kleine-König wrote:
> > > > Hello,
> > > >
> > > > this is the set of patches that are open on the list for some time.
> > > > Lee suggested to resend them.
> > > >
> > > > @Thierry: I'm unsure what is the best way to nag. Is it really
> > > > resending? Or does this just result mostly in overhead because the
> > > > patches are still open in patchwork and it adds copies to your mailbox?
> > > > (Another downside is that taking the patches from this thread results in
> > > > recording a newer Author Date compared to picking up the originals.)
> > >
> > > I use patchwork extensively for tracking, so merely resending patches so
> > > that they float to the top of my inbox isn't useful in itself. Patches
> > > do, by the way, float to the top of my inbox when you just reply to them
> > > (e.g. by pinging). Resending a particular series is fine because it's
> > > then easy to mark the old version as "superseded". Sending a collection
> > > of patch such as this is a bit more annoying because now the duplicates
> > > are spread about a bit more in patchwork, so it's a bit more work to get
> > > patchwork cleaned up. But it's not that bad, so no harm done.
> > >
> > > Usually when I look at patchwork I will look at the A/F/R/T column and
> > > the more flags I see there, the more likely I will be to go and apply
> > > it. Anything else I will go and look at myself and comment and/or apply
> > > or sometimes wait for someone else to review.
> > >
> > > Perhaps a better way to nag me would be to delegate patches that you've
> > > reviewed or think are ready to me, which would make them stand out more
> > > among the others.
> >
> > It's not Uwe's fault, it's mine.
> >
> > Since some of Uwe's patches had been left unreviewed for several
> > weeks, I asked him to collect up all of his dangling patches and
> > submit this resend for *me* to review.
>
> Like I said, it's not a big deal. And I'm also aware that this is misery
> of my own making, so no worries.
>
> > As someone who does not use Patchwork, I find this to be the simplest
> > and cleanest method of patch collation. Going by your almost
> > immediate reply, I guess it had a nice desired side-effect. :)
>
> Indeed, it achieved the desired effect, so can't argue about its
> effectiveness. =)
=:D
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH 00/14] pwm: Patches I consider ready for the next merge window
2021-03-23 7:19 ` Lee Jones
2021-03-23 8:53 ` Thierry Reding
@ 2021-04-08 10:43 ` Uwe Kleine-König
1 sibling, 0 replies; 21+ messages in thread
From: Uwe Kleine-König @ 2021-04-08 10:43 UTC (permalink / raw)
To: Thierry Reding, Lee Jones; +Cc: linux-pwm, kernel
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
Hello Thierry, hello Lee,
On Tue, Mar 23, 2021 at 07:19:29AM +0000, Lee Jones wrote:
> Since some of Uwe's patches had been left unreviewed for several
> weeks
We're nearly there again. There are currently 30 open patches in
patchwork:
- There is the pca9685 series by Clemens Gruber. Some of the patches
are already marked as changes-requested, but the newly proposed
staggering-allowed stuff could get some attention by one of you. I'm
a bit ambivalent as I wrote in my reply. I don't feel competent to
comment the runtime PM stuff (patch 1).
- A series to convert the rockchip dt binding to yaml, here I'd wait
for Heiko Stübner to comment. I didn't look in detail but didn't spot
anything obvious to criticise.
- In sum 21 patches by me, some got an Ack by the respective driver
maintainers, some are already >2 weeks on the list. Most of them
didn't get any attention by you.
:-\
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread