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? -- 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
