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

[Josh Boyer <jwboyer@linux.vnet.ibm.com>]

On Thu, 05 Jun 2008 13:35:18 -0500
Timur Tabi <timur@freescale.com> wrote:

> 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.

Which isn't a problem.

> 2) That the nodes in the device tree are put in order

Which isn't a problem.

> 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.

Your driver is sufficiently different then.  The i2c-ibm_iic driver
keeps an index property in it's private device structure.

> > 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.

Sort of.

> > (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.

I've been driven to the point of not caring anymore.

If you need a simple index property, then maybe Sean was right to just
call the damn thing "index".  Overloading "cell-index", which already
has a specific semantic associated with it, seems odd to me.

josh