On Thu, 05 Jun 2008 13:35:18 -0500 Timur Tabi <[EMAIL PROTECTED]> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
