> However. If there really is an SMBus slave device that is asserting > SMBALERT#, ignoring it will mean that the interrupt handler gets > called over and over again. That's probably not going to be a > full-blown interrupt storm as the SMBus device is fairly low-speed. > But what we really should do the SMBALERT# dance of reading the Alert > Response Address, which will make sure the device de-asserts the > SMBALERT# line.
A log Stefan shared with me seems to indicate that alert is being generated for each transaction to a non-existant device, plus also for a few addresses on the spdmem. It is very strange. It makes me think there is some sort of iic "hub" or "switch" in the way, doing something very strange. We may never get to the bottom of this because is undocumented space with strange behaviours, hell for all we know they left the SMBALERT pin floating and it is next to something noisy... > But what we really should do the SMBALERT# dance of reading the Alert > Response Address, which will make sure the device de-asserts the > SMBALERT# line. Ah, I did not check the spec. That sounds very reasonable... > If we're going with this diff, it would be good to add an XXX comment > that we ignore SMBALERT# for now. I later asked for that ridiculous if statement to be split into different blocks, for the various reasons.
