Josh Boyer wrote: > I don't understand this statement. Are your I2C macros hot-pluggable? > Can you dynamically add/remove an I2C engine on your hardware somehow? > Are you mucking about with the DTB and randomly moving around the I2C > node blobs so they probe order differs from boot to boot? > > If not, then the probe order will be static for every boot.
You're making two assumptions: 1) That every I2C adapter will be present in the device tree. Some device trees don't list I2C adapters if there are no devices on them. 2) That the nodes in the device tree are put in order Besides, let's say I have a pointer to a specific I2C device node in the tree. How do I find out the bus number it's on? With my way, it's easy: iprop = of_get_property(of_get_parent(codec_np), "cell-index", NULL); bus = *iprop; With your way, I'll need to scan the entire device tree, poking inside each I2C adapter node looking for my I2C device node while keeping track of the I2C adapters. > You can > assign the index Assign it to where? When the fabric driver goes to find codec nodes, the only information it has is the device tree. So when I assign this index to some random variable that you're talking about, my fabric driver will know nothing about that. > using a static int that is incremented after each node > is discovered and the ordering of the devices will never change. Can > you explain why something like that isn't possible or sufficient? Yes, I just did. > (And I'm talking about I2C, not DMA. I don't care about DMA because > this conversation will go off into the weeds if we start talking about > cell-index and every possible device out there.) But we are talking about every device. It's the same problem for every device. Making this problem I2C-specific is not going to solve anything. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
