[lkml]   [2011]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] staging:iio:proof of concept in kernel interface.
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:

dev_name of underlying hardware if specified.
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

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

 \ /
  Last update: 2011-10-14 18:01    [W:0.099 / U:10.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site