> Date: Sat, 12 Mar 2016 19:44:56 +0100 > From: Stefan Sperling <[email protected]> > > On Sat, Mar 12, 2016 at 02:19:49PM +0100, Stefan Sperling wrote: > > I now prefer this diff. I can make additional code cleanups in this driver > > in separate commits. But this is enough to fix the problem and matches what > > FreeBSD (dev/ichsmb) and Linux (drivers/i2c/busses/i2c-i801.c) do with > > regard to SMBALERT# -- just ignore it. > > I'll add that a bios update fixes the problem, too. > (Thanks to RD Thrush for the hint!) > > ADI BIOS releases (with coreboot sources) are here: > https://github.com/ADIEngineering/adi_coreboot_public/tree/master/releases > > Version ADI_RCCVE-01.00.00.03 has the bug. > Version ADI_RCCVE-01.00.00.08 does not have the bug. > > With version .08, the interrupts become: > > ichiic0: intr st 0x42<INTR,INUSE> > > instead of: > > ichiic0: intr st 0x62<INTR,SMBAL,INUSE> > > I still think we should work around the problem, if possible. > I still have a board with a buggy bios to test with (and could > always reflash older versions, I presume).
Simply ignoring the SMBALERT_STS bit, like your latest diff does, is a bit dangerous. It seems that on later generations of the controller there is a SMBALERT_DIS bit in the SLV_CMD register that determines whether SMBALERT_STS actually causes an interrupt or not. I suppose this bit is set on your board. But it may be cleared on other hardware. And on such hardware, simply ignoring the SMBALERT_STS will trigger an interrupt storm. Not sure if clearing the SMBALERT_STS bit is enough to prevent such a storm, but I think we should at least try to do that, like you did in one of the earlier diffs.
