On 03/11/15 16:31, Brian Norris wrote: > On Tue, Nov 03, 2015 at 06:08:40PM +0800, Axel Lin wrote: >> 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. >> >> 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. > > 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? -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
