Patch "pwm: sifive: Always let the first pwm_apply_state succeed" has been added to the 6.2-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    pwm: sifive: Always let the first pwm_apply_state succeed

to the 6.2-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pwm-sifive-always-let-the-first-pwm_apply_state-succ.patch
and it can be found in the queue-6.2 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit e7acb7289a497397ecf91c32e2c3e879ec1ad55c
Author: Emil Renner Berthing <emil.renner.berthing@xxxxxxxxxxxxx>
Date:   Wed Nov 9 12:37:24 2022 +0100

    pwm: sifive: Always let the first pwm_apply_state succeed
    
    [ Upstream commit 334c7b13d38321e47d1a51dba0bef9f4c403ec75 ]
    
    Commit 2cfe9bbec56ea579135cdd92409fff371841904f added support for the
    RGB and green PWM controlled LEDs on the HiFive Unmatched board
    managed by the leds-pwm-multicolor and leds-pwm drivers respectively.
    All three colours of the RGB LED and the green LED run from different
    lines of the same PWM, but with the same period so this works fine when
    the LED drivers are loaded one after the other.
    
    Unfortunately it does expose a race in the PWM driver when both LED
    drivers are loaded at roughly the same time. Here is an example:
    
      |          Thread A           |          Thread B           |
      |  led_pwm_mc_probe           |  led_pwm_probe              |
      |    devm_fwnode_pwm_get      |                             |
      |      pwm_sifive_request     |                             |
      |        ddata->user_count++  |                             |
      |                             |    devm_fwnode_pwm_get      |
      |                             |      pwm_sifive_request     |
      |                             |        ddata->user_count++  |
      |         ...                 |          ...                |
      |    pwm_state_apply          |    pwm_state_apply          |
      |      pwm_sifive_apply       |      pwm_sifive_apply       |
    
    Now both calls to pwm_sifive_apply will see that ddata->approx_period,
    initially 0, is different from the requested period and the clock needs
    to be updated. But since ddata->user_count >= 2 both calls will fail
    with -EBUSY, which will then cause both LED drivers to fail to probe.
    
    Fix it by letting the first call to pwm_sifive_apply update the clock
    even when ddata->user_count != 1.
    
    Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM")
    Signed-off-by: Emil Renner Berthing <emil.renner.berthing@xxxxxxxxxxxxx>
    Signed-off-by: Thierry Reding <thierry.reding@xxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index 62b6acc6373db..393a4b97fc19e 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -161,7 +161,13 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	mutex_lock(&ddata->lock);
 	if (state->period != ddata->approx_period) {
-		if (ddata->user_count != 1) {
+		/*
+		 * Don't let a 2nd user change the period underneath the 1st user.
+		 * However if ddate->approx_period == 0 this is the first time we set
+		 * any period, so let whoever gets here first set the period so other
+		 * users who agree on the period won't fail.
+		 */
+		if (ddata->user_count != 1 && ddata->approx_period) {
 			mutex_unlock(&ddata->lock);
 			return -EBUSY;
 		}