"cell-index" vs. "index" vs. no index in I2C device nodes
jwboyer at linux.vnet.ibm.com
Fri Jun 6 04:40:57 EST 2008
On Thu, 05 Jun 2008 13:35:18 -0500
Timur Tabi <timur at 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.
> > (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.
More information about the Linuxppc-dev