On Thu, Mar 03, 2022 at 02:48:20PM +0200, Tali Perry wrote:
> > On Thu, Mar 3, 2022 at 12:37 PM Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > >
> > > On Thu, Mar 03, 2022 at 04:31:39PM +0800, Tyrone Ting wrote:
> > > > From: Tali Perry <tali.perry1@xxxxxxxxx>
> > > >
> > > > In order to better handle spurious interrupts:
> > > > 1. Disable incoming interrupts in master only mode.
> > > > 2. Clear end of busy (EOB) after every interrupt.
> > > > 3. Return correct status during interrupt.
> > >
> > > This is bad commit message, it doesn't explain "why" you are doing these.
...
> BMC users connect a huge tree of i2c devices and muxes.
> This tree suffers from spikes, noise and double clocks.
> All these may cause spurious interrupts to the BMC.
>
> If the driver gets an IRQ which was not expected and was not handled
> by the IRQ handler,
> there is nothing left to do but to clear the interrupt and move on.
Yes, the problem is what "move on" means in your case.
If you get a spurious interrupts there are possibilities what's wrong:
1) HW bug(s)
2) FW bug(s)
3) Missed IRQ mask in the driver
4) Improper IRQ mask in the driver
The below approach seems incorrect to me.
> If the transaction failed, driver has a recovery function.
> After that, user may retry to send the message.
>
> Indeed the commit message doesn't explain all this.
> We will fix and add to the next patchset.
>
> > > > + /*
> > > > + * if irq is not one of the above, make sure EOB is disabled and all
> > > > + * status bits are cleared.
> > >
> > > This does not explain why you hide the spurious interrupt.
> > >
> > > > + */
> > > > + if (ret == IRQ_NONE) {
> > > > + npcm_i2c_eob_int(bus, false);
> > > > + npcm_i2c_clear_master_status(bus);
> > > > + }
> > > > +
> > > > + return IRQ_HANDLED;
--
With Best Regards,
Andy Shevchenko
