On 09/07/2016 09:54 AM, Linus Walleij wrote:
On Sun, Sep 4, 2016 at 6:22 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
The nasty here is that we need to validate that the trigger is associate
with this device 'before' allowing others to associate. Could be done I
think in a slightly more than average complexity validate call.
* If another trigger is used then pollfunc would have to initialize a oneshot
read as you already have it doing.
I guess the new function iio_trigger_using_own() would be pretty helpful
for this driver too.
Yes! I was just looking at your patch :) It would allow me to get rid of
pointer to own trigger stored in iio device's private state.
Good point.
Do you think we can merge patch 1+2 of that series (adding the function
and using it with the ST sensors) and I will squash patch
3 into my pending MPU-3050 driver and then this driver can rely on it
as well?
The way I see it is that when handling triggers we should always handle
our own as well as any external trigger (e.g. HRTimer, or even a trigger
from a different sensor...)
Yours,
Linus Walleij
--
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
