Re: [lm-sensors] [patch 2.6.27-rc7] i2c: smbalert# support

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

... 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

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c