On Wed, 2015-01-28 at 11:22 +0200, Octavian Purdila wrote: > On Tue, Jan 6, 2015 at 8:53 PM, Srinivas Pandruvada > <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote: > > > > On Sun, 2015-01-04 at 16:21 +0000, Jonathan Cameron wrote: > > > On 21/12/14 00:42, Octavian Purdila wrote: > > > > Move the slope duration and threshold update in separate functions > > > > to reduce code duplicate between chip init and motion interrupt setup. > > > > > > > > The patch also moves the update from the motion interrupt setup > > > > function to the write event function so that we can later refactor the > > > > interrupt code. > > > The side effect of this is that these will get updated at a different > > > point in time from before. Previously these values would only get > > > updated when the event was enabled (or the trigger). So to change > > > them a disable / enable cycle was needed. Now they happen the moment > > > they are relevant. > > > > > > I prefer the new option, but it is an ABI change (be it one most people > > > won't notice!) > > I did purposely this way. > > IMO when user is changing critical parameters he should disable and re > > enable to avoid undesirable side effects. > > We have similar situation in other thermal drivers where user can > > change policy parameters. Initially we let them change while zone is > > enabled (system is armed), this led to undesirable side effects due to > > race conditions. > > > > We already have a check that prevents the change while the event is > active. We could add a check for the data motion trigger as well, to > avoid the above scenario. > > Alternatively I can rewrite the patch to keep the current behavior and > update the parameters when we enable the trigger. > > Which one sounds better? I prefer the second option. Thanks, Srinivas -- 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
