(2013/06/22 14:25), Tom Zanussi wrote: > > Looking into this a bit more, I think the reason it hasn't bothered > anyone until now is that it's been hidden by the existing > event_enable_read() implementation, which doesn't show any soft disable > state when the event is actually disabled, only when it's enabled. So > the case where SOFT_DISABLED is still set but the event is actually > disabled gets hidden by the catch-all "0" case. > > My new version of event_enable_read() does show the soft disabled state > when the event is actually disabled, which is why I noticed it wasn't > getting turned off, and led to the current patch. > > Ironically, the reason I refactored the function in the first place was > to add the '+' flag for triggers - redundant, yes, but useful for > debugging, not quite in the way I planned though. ;-) (It might be > that leaving the current function in place and remaining oblivious would > be ok, too, since it doesn't seem to really cause much of a problem in > any case...) >
Ah, I've just missed this. And indeed, if your event_enable_read() cleanup patch changes the output, that is not actual cleanup patch. I think you should merge this into [1/11] patch to avoid behavior change. Thank you! -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
