On Fri, Nov 2, 2012 at 4:00 AM, Felipe Balbi [off-list ref] wrote:

Hi,

On Fri, Nov 02, 2012 at 02:42:51AM -0700, Russ Dill wrote:

quoted

quoted

quoted

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.

quoted

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.

quoted

quoted

quoted

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.