Hi, On Fri, Nov 02, 2012 at 02:42:51AM -0700, Russ Dill wrote: > >> browse through various detect functions, yes, some of them key off an > >> ID, but a lot of them just check various registers to see if certain > >> bits are zero, or certain bits are one. A lot of I²C devices I've > >> dealt with have no good way of probing them, especially GPIO chips > >> (you'll notice none of the I²C GPIO expanders have detect functions) > > > > it doesn't mean it can't be done. > > Really? Please, do tell how you would write a detect function for a > PCA9534. It has 4 registers, an input port registers, an output port > register, a polarity inversion register, and a configuration register. read them and match to their reset values, perhaps ? > And don't forget, since we are probing, every detect routine for every > I²C driver will have to run with every I²C address on every bus, > possibly with both address formats. not *every* I2C address. What you say is wrong, a ->detect() method will only run for those addresses which the device can actually assume. > >> On top of all this the detect routine does not tell you if the alert > >> pin is connected to some IRQ, or in the case of a GPIO expander, what > >> those GPIOs are connected to, etc, etc. > > > > so what ? All you want to do with detect is figure out if the far end is > > who you think it is, not what it's doing. > > If we already knew who was there, we wouldn't need a detect routine. of course not :-) But the whole discussion has been about not knowing which capes (and thus which devices) are attached to the bone. -- balbi
Attachment:
signature.asc
Description: Digital signature
