... just to recap this before I scrub old mail from my mbox: On Friday 26 September 2008, Trent Piepho wrote: > > It's not a question of the I2C adapter supporting it. ?It's a > > question of whether there's an SMBALERT# signal on your board, > > which can generate an interrupt. ?If it can, this patch has an > > IRQ handler which implements the SMBus alert protocol. ?Think > > of it as sideband signaling ... unknown to that adapter. > > If nothing is alerting, then the read from the ARA address won't get an ack. This is indeed how the SMBALERT# protocol handling code must detect that all pending alerts have been handled: each read of ARA clears one pending alert, until none responds any more. (And the active-low open drain SMBALERT# signal went high.) > Some i2c adapters don't handle this so well. If your system can't implement the SMBALERT# protocol, then there's no problem at all. Just handle the IRQ using whatever non-standard hackery is necessary to cope with that hardware, and DO NOT tell Linux that it's really SMBALERT#. Simple. The SMBALERT# protocol is very specific about how it acts and what it does. It's also very specific to SMBus. The $SUBJECT patch never claimed to be an attempt to work with arbitrary collections of I2C device interrupts that weren't designed to cooperate at all, much less to follow the SMBALERT# rules. Absolutely nothing you've said makes a real argument against providing support for SMBALERT#. At best, you've made an argument that some drivers may need to support less-efficient IRQ dispatching schemes as well as SMBALERT#, in order to handle board-specific design quirks. - Dave
