pwm: brcmstb: Don't set can_sleep flag
Subsystems (2)
PATCH 1/1 pwm: brcmstb: Don't set can_sleep flag
The .can_sleep flag is used for some PWM controllers that can't be used in atomic context. Not such case for this driver, so don't set the can_sleep flag.
--- drivers/pwm/pwm-brcmstb.c | 1 - 1 file changed, 1 deletion(-)
drivers/pwm/pwm-brcmstb.c +0 -1
@@ -270,7 +270,6 @@ static int brcmstb_pwm_probe(struct platform_device *pdev) p->chip.ops = &brcmstb_pwm_ops; p->chip.base =-1 ; p->chip.npwm =2 ; - p->chip.can_sleep = true; res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); p->base =devm_ioremap_resource (&pdev->dev, res);
Signature · 1 line
2.1.4
Quoted 5 lines · Axel Lin
The .can_sleep flag is used for some PWM controllers that can't be used in atomic context. Not such case for this driver, so don't set the
can_sleepflag.Signed-off-by Axel Lin <[email protected]>
Thanks!
Quoted 17 lines
--- drivers/pwm/pwm-brcmstb.c | 1 - 1 file changed, 1 deletion(-)drivers/pwm/pwm-brcmstb.c +0
-1@@ -270,7 +270,6 @@ static int brcmstb_pwm_probe(struct platform_device *pdev) p->chip.ops = &brcmstb_pwm_ops; p->chip.base =-1 ; p->chip.npwm =2 ; - p->chip.can_sleep = true; res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); p->base =devm_ioremap_resource (&pdev->dev, res);
Signature · 1 line
Florian
Quoted 5 lines · Axel Lin
The .can_sleep flag is used for some PWM controllers that can't be used in atomic context. Not such case for this driver, so don't set the
can_sleepflag.Signed-off-by Axel Lin <[email protected]>
Looks sane to me, though I've never touched this driver.
BTW just a comment from an outsider here, the "can sleep" terminology seems a bit misleading here. Just IMO of course, but saying something "can sleep" sounds like a permissive statement, when actually it's a restrictive statement being made by the driver (which is in this case unnecessarily restrictive). The "might sleep" terminology used in one other place would (again IMO) better communicate what I think is intended here.
Though this problem is most likely result of mindless copy-and-paste, it's possible that the terminology made it easier to gloss over. Or I could just be blowing smoke.
Regards,
Brian
Quoted 21 lines
--- drivers/pwm/pwm-brcmstb.c | 1 - 1 file changed, 1 deletion(-)drivers/pwm/pwm-brcmstb.c +0
-1@@ -270,7 +270,6 @@ static int brcmstb_pwm_probe(struct platform_device *pdev) p->chip.ops = &brcmstb_pwm_ops; p->chip.base =-1 ; p->chip.npwm =2 ; - p->chip.can_sleep = true; res =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); p->base =devm_ioremap_resource (&pdev->dev, res);Signature · 1 line
2.1.4
Quoted 19 lines · Brian Norris
Quoted 5 lines · Axel Lin
The .can_sleep flag is used for some PWM controllers that can't be used in atomic context. Not such case for this driver, so don't set the
can_sleepflag.Signed-off-by Axel Lin <[email protected]>Looks sane to me, though I've never touched this driver.
Reviewed-by Brian Norris <[email protected]>BTW just a comment from an outsider here, the "can sleep" terminology seems a bit misleading here. Just IMO of course, but saying something "can sleep" sounds like a permissive statement, when actually it's a restrictive statement being made by the driver (which is in this case unnecessarily restrictive). The "might sleep" terminology used in one other place would (again IMO) better communicate what I think is intended here.
Quoted 3 lines
Though this problem is most likely result of mindless copy-and-paste, it's possible that the terminology made it easier to gloss over. Or I could just be blowing smoke.
Well, in this particular case, I have to admit this was copy and paste which resulted in setting can_sleep initially.
Now, I do agree that the terminology is a little confusing here. If you look at the GPIO API there are gpio_*_cansleep() accessors, which in their case, convey the correct meaning: the operation can/might sleep.
Should we prepare a coccinelle script which fixes that at least for the PWM subsystem?
Signature · 1 line
Florian
Quoted 3 lines · Florian Fainelli
Now, I do agree that the terminology is a little confusing here. If you look at the GPIO API there are gpio_*_cansleep() accessors, which in their case, convey the correct meaning: the operation can/might sleep.
Perhaps I'm misreading, but that actually sounds exactly the same as the pwm_can_sleep() API. It sounds OK from a consumer/API perspective, but I was just commenting on the perspective of the driver writer.
Maybe it's not worth much change, then, if several subsystems have similar naming.
Brian