Re: "cell-index" vs. "index" vs. no index in I2C device nodes

[Timur Tabi <timur@freescale.com>]

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