On Tue 08 May 05:26 PDT 2018, kgunda@xxxxxxxxxxxxxx wrote: > On 2018-05-07 22:51, Bjorn Andersson wrote: > > On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote: [..] > > > @@ -220,7 +255,12 @@ static int wled_module_enable(struct wled > > > *wled, int val) > > > WLED3_CTRL_REG_MOD_EN, > > > WLED3_CTRL_REG_MOD_EN_MASK, > > > WLED3_CTRL_REG_MOD_EN_MASK); > > > - return rc; > > > + if (rc < 0) > > > + return rc; > > > + > > > + schedule_delayed_work(&wled->ovp_work, WLED_SOFT_START_DLY_US); > > > > Do you really want to delay the work on disable? > > > > Wouldn't it be better to use a delay worker for the enablement and in > > the disable case you cancel the work and just disable_irq() directly > > here. > > > Sure. Will do it in the next series. > > But more importantly, if this is only related to auto detection, do you > > really want to enable/disable the ovp_irq after you have detected the > > string configuration? > > > Ok. This is used for the genuine OVP detection and for the auto detection as > well. What is the expected outcome of detecting an OVP condition, outside auto detection? Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
