On 06/05/2015 01:54 PM, MyungJoo Ham wrote: >> >> IRQ signal before driver probe is needless because driver sends >> current state after platform booting done. >> So, this patch clears MUIC IRQ bits before request IRQ. >> >> Signed-off-by: Jaewon Kim <jaewon02....@samsung.com> >> --- >> drivers/extcon/extcon-max77843.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) > > Q1. Is this because the pending bits are USELESS? > or because the pendeing bits incurs INCORRECT behaviors?
The max77843 datasheet includes following sentence: - "All bits are cleared after a read" about INT1/INT2/INT3 register. There are no problem about interrupt handling. > > Q2. Does clearing (by reading) INT1 do everything you need? > What about INT2 and INT3? The MAXIM MAX77843 MUIC support the one more interrupts (e.g., ADC1K, VBVolt, ChgTyp ...). The each interrupt is included in the one register among INT1/2/3. This patch clear the all interrupts of MAX77843 before requesting the interrupts. > > Q3. I presume that "driver sends current state after..." is > coming from the invokation of "queue_delayed_work()" at the end > of the probe function. It appears that you are only serving > the pending status of "cable detection" with it while INT1 > seems to have more functionalities. Does that delayed work > do everything that are pending, really? When completed kernel booting, the delayed work of extcon-max77843.c driver use the MAX77843_MUIC_STATUSx register to detect the type of connected external connectors. So, there are no problme about clearing all bits of INT1/2/3 interrupt register. If user-space platform don't finish the initialization of all user-process daemons and extcon driver send the uevent during only kernel booting, the uevent is not handled on user-space daemons. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
