On 06/11/2013 11:08 PM, Lars-Peter Clausen wrote: >>> This doesn't work in general. The index is not the same as channel >>> (or any other form of index present). Note that modified channels may >>> all have channel set to 0 (accel_x, accel_y etc for instance). >>> >>> The index refers directly into those channels registered. >>> Is it possible for channels to move at runtime between the two units? >>> I would imagine not as this is very much a case of wiring. >>> >>> Thus we have a fairly messy bit if interdependence in the device >>> tree but it should work. >>> >>> I don't actually have much / any real experience of device tree configurations >>> and this is Guenter's code, hence I have cc'd him. >>> >>> Note that it is acceptable and relatively common to have missing >>> values in scan_index but that isn't really relevant here. >>> >>> Jonathan >> >> Too long ago since I looked into that, but this code changes the API >> from "get nth channel" to "channel with channel index n". >> Not really sure I understand why that should be necessary. >> > > yea, this will definitively not work channels of different types will > usually have the same channel numbers. I see. I've been looking at the Documentation. It says "IIO specifier" for the second argument. Now I assumed it is referred to the channel number and not the order of channel registration. The "read" requests (in the drivers I checked) checked the channel's number in order to associate the request with the wire. I see now some use the "address" field. So it kind of looked like a bug where one did not assume that the channel number could start at != 0. It is either the documentation or me reading it. I guess it is the latter. Anyway, if this is the intention of the parameter, just drop the patch and everything is fine :) Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
