On Fri, Nov 2, 2012 at 4:00 AM, Felipe Balbi <balbi@xxxxxx> wrote: > 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 ? So its ok for it to not work on warm reset? Also, I'm pretty sure [ random, 0xff, 0x00, 0xff ] describes quite a few chips. >> 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. OK, that's still a potentially large number of addresses. >> >> 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. Eh? Finding out which bone is connected is pretty easy, they all have an EEPROM with identifying information. That isn't the problem that capebus is solving, capebus is solving the problem of enumerating that hardware. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
