On 10/13/11 21:44, Mark Brown wrote: > On Thu, Oct 13, 2011 at 03:46:04PM +0100, Jonathan Cameron wrote: > >>> I guess an actual implementation would have wrappers for doing the >>> indirections rather than having users peer into the ops table directly? > >> Yup, for some reason the cover letter seems to have detached from this. >> It suggested exactly that. There may be weird cases where peering this >> deep into the ops makes sense, but not for something like this one. > > Oh, right. As a general rule I don't read cover letters for single > patches until after I've read the patch, generally they're either > completely content free (if only by virtue of repeating the changelog) > or there's a problem with the changelog in the actual patch not > explaining what's going on. Fair enough. I'm trying to work out what our equivalent of the clk finding api is. The best match pair to match on I can come up with is: part name: iio_dev.name dev_name of underlying hardware if specified. dev_name(iio_dev->dev.parent) This matching source can be overridden by an optional callback if we unique matching is achievable in some other way for the device. Typical pairs: max1363, 0-0035 max1238, 0-0034 lis3l02dq spi1.0 adis16400 spi2.1 On soc ADCs can use any combination of the two that makes local sense. Does this look sufficient for description / identification? Precedence order of both, then column 2 (lets call that id) and finally column 1 (part name). The concept of connections doesn't make sense quite like it does for clks as we are getting a reference to the whole device, then picking which bits we want afterwards. -- 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
