Re: [PATCH v2 05/11] iio: bmc150: refactor slope duration and threshold update

[Octavian Purdila <octavian.purdila@intel.com>]

On Tue, Jan 6, 2015 at 8:53 PM, Srinivas Pandruvada
<srinivas.pandruvada@linux.intel.com> 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?