Messages in this thread | | | Date | Mon, 30 Jan 2023 16:36:31 +0100 | From | Thierry Reding <> | Subject | Re: [PATCH v2] pwm: sifive: Always let the first pwm_apply_state succeed |
| |
On Wed, Nov 09, 2022 at 12:37:24PM +0100, Emil Renner Berthing wrote: > 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@canonical.com> > --- > drivers/pwm/pwm-sifive.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-)
I've applied this as-is for now. What I'm wondering is if perhaps we want to implement something into the PWM core to deal with this, now fairly common, situation.
Thierry [unhandled content-type:application/pgp-signature] | |