Re: [PATCH v4 1/4] regulator: Add set_voltage_time op
El Mon, Sep 12, 2016 at 06:18:31PM -0700 Matthias Kaehlcke ha dit:
> El Tue, Sep 13, 2016 at 12:57:58AM +0100 Mark Brown ha dit:
>
> > On Mon, Sep 12, 2016 at 04:18:51PM -0700, Matthias Kaehlcke wrote:
> > > El Mon, Sep 12, 2016 at 07:32:30PM +0100 Mark Brown ha dit:
> > > > On Tue, Sep 06, 2016 at 12:03:15PM -0700, Matthias Kaehlcke wrote:
...
> > > > Why were the gotos there?
> >
> > > Not sure how to interpret your question. Would you prefer no to use
> > > gotos, should the notification be skipped in case the voltage is not
> > > changed, do you expect a comment, ...?
> >
> > I mean I couldn't tell why a goto was a good idea for what seemed like
> > perfectly normal conditional logic. Either I couldn't tell because it's
> > not a good idea or it is a good idea but should be clearer in some way
> > but since I didn't really understand what the purpose of doing the gotos
> > was I can't say for sure either way.
>
> The main purpose is to avoid deeply nested code branches.
>
> Without gotos I think we'd end up with something like this:
>
> static int _regulator_do_set_voltage(struct regulator_dev *rdev,
> int min_uV, int max_uV)
> {
> ...
> if (ret == 0 && !rdev->constraints->ramp_disable) {
> if (rdev->desc->ops->set_voltage_time_sel) {
> if (old_selector >= 0 && old_selector != selector)
> rdev->desc->ops->set_voltage_time_sel(rdev,
> old_selector, selector);
> } else {
> if (old_uV != new_uV) {
> if (rdev->desc->ops->set_voltage_time)
> delay =
> rdev->desc->ops->set_voltage_time(rdev, old_uV, new_uV);
> else
> delay =
> _regulator_set_voltage_time(rdev, old_uV, new_uV);
> }
> }
>
> // delay
> }
> }
>
> I can change the patch accordingly if this is preferred.
The above improves a bit when a local ops variable is used instead of
rdev->desc->ops. With that it looks bearable and probably better than
the goto version.
Re: [PATCH v4 1/4] regulator: Add set_voltage_time op
El Tue, Sep 13, 2016 at 12:57:58AM +0100 Mark Brown ha dit:
> On Mon, Sep 12, 2016 at 04:18:51PM -0700, Matthias Kaehlcke wrote:
> > El Mon, Sep 12, 2016 at 07:32:30PM +0100 Mark Brown ha dit:
> > > On Tue, Sep 06, 2016 at 12:03:15PM -0700, Matthias Kaehlcke wrote:
>
> > > > - /* Call set_voltage_time_sel if successfully obtained
> > > > old_selector */
> > > > - if (ret == 0 && !rdev->constraints->ramp_disable &&
> > > > old_selector >= 0
> > > > - && old_selector != selector) {
> > > > + if (ret != 0 || rdev->constraints->ramp_disable)
> > > > + goto no_delay;
>
> > > You probably want to do the refactoring for splitting out decisions
> > > about old_selector separately, it'll make the diff clearer.
>
> > The old_selector conditions could be moved into the "else if
> > (rdev->desc->ops->set_voltage_sel)" branch above, is that you mean?
>
> No, what I mean is this change is doing a bunch of moving code around as
> well as adding new things which makes it hard to spot where the new
> things are. Moving the code around separately (that is, in a separate
> patch) would make the review easier.
Moving the code around is related with the gotos, which are related
with the new set_voltage_sel. If we can agree that using goto is the
right thing to do (please see my rationale below) I could create a
separate patch introducing it. However this will only somewhat
mitigate the code moving around, since we still need separate paths
for set_voltage_time and set_voltage_time_sel.
> > > > + /* Insert any necessary delays */
> > > > + if (delay >= 1000) {
> > > > + mdelay(delay / 1000);
> > > > + udelay(delay % 1000);
> > > > + } else if (delay) {
> > > > + udelay(delay);
> > > > + }
>
> > > > +no_delay:
>
> > > Why were the gotos there?
>
> > Not sure how to interpret your question. Would you prefer no to use
> > gotos, should the notification be skipped in case the voltage is not
> > changed, do you expect a comment, ...?
>
> I mean I couldn't tell why a goto was a good idea for what seemed like
> perfectly normal conditional logic. Either I couldn't tell because it's
> not a good idea or it is a good idea but should be clearer in some way
> but since I didn't really understand what the purpose of doing the gotos
> was I can't say for sure either way.
The main purpose is to avoid deeply nested code branches.
Without gotos I think we'd end up with something like this:
static int _regulator_do_set_voltage(struct regulator_dev *rdev,
int min_uV, int max_uV)
{
...
if (ret == 0 && !rdev->constraints->ramp_disable) {
if (rdev->desc->ops->set_voltage_time_sel) {
if (old_selector >= 0 && old_selector != selector)
rdev->desc->ops->set_voltage_time_sel(rdev,
old_selector, selector);
} else {
if (old_uV != new_uV) {
if (rdev->desc->ops->set_voltage_time)
delay =
rdev->desc->ops->set_voltage_time(rdev, old_uV, new_uV);
else
delay =
_regulator_set_voltage_time(rdev, old_uV, new_uV);
}
}
// delay
}
}
I can change the patch accordingly if this is preferred.
> > > The diff and I expect the resulting code would be a lot clearer if we
> > > just left most of the function indented as it is and simply directly
> > > returned set_voltage_time(). Which is what we do anyway so no need to
> > > reindent the rest of the code.
>
> > Ok, with your comment below on a default implementation this would
> > become something like:
>
> > if (ops->set_voltage_time) {
> > return ops->set_voltage_time(...);
> > } else if (!ops->set_voltage_time_sel) {
> > return _regulator_set_voltage_time(..);
> > }
>
> I suspect you'll end up with more refactoring than that around
> _set_voltage_time() and this'll be inside that function but I've lost
> context here so ICBW.
Re: [PATCH v4 1/4] regulator: Add set_voltage_time op
On Mon, Sep 12, 2016 at 04:18:51PM -0700, Matthias Kaehlcke wrote:
> El Mon, Sep 12, 2016 at 07:32:30PM +0100 Mark Brown ha dit:
> > On Tue, Sep 06, 2016 at 12:03:15PM -0700, Matthias Kaehlcke wrote:
> > > - /* Call set_voltage_time_sel if successfully obtained old_selector */
> > > - if (ret == 0 && !rdev->constraints->ramp_disable && old_selector >= 0
> > > - && old_selector != selector) {
> > > + if (ret != 0 || rdev->constraints->ramp_disable)
> > > + goto no_delay;
> > You probably want to do the refactoring for splitting out decisions
> > about old_selector separately, it'll make the diff clearer.
> The old_selector conditions could be moved into the "else if
> (rdev->desc->ops->set_voltage_sel)" branch above, is that you mean?
No, what I mean is this change is doing a bunch of moving code around as
well as adding new things which makes it hard to spot where the new
things are. Moving the code around separately (that is, in a separate
patch) would make the review easier.
> > > + /* Insert any necessary delays */
> > > + if (delay >= 1000) {
> > > + mdelay(delay / 1000);
> > > + udelay(delay % 1000);
> > > + } else if (delay) {
> > > + udelay(delay);
> > > + }
> > > +no_delay:
> > Why were the gotos there?
> Not sure how to interpret your question. Would you prefer no to use
> gotos, should the notification be skipped in case the voltage is not
> changed, do you expect a comment, ...?
I mean I couldn't tell why a goto was a good idea for what seemed like
perfectly normal conditional logic. Either I couldn't tell because it's
not a good idea or it is a good idea but should be clearer in some way
but since I didn't really understand what the purpose of doing the gotos
was I can't say for sure either way.
> > The diff and I expect the resulting code would be a lot clearer if we
> > just left most of the function indented as it is and simply directly
> > returned set_voltage_time(). Which is what we do anyway so no need to
> > reindent the rest of the code.
> Ok, with your comment below on a default implementation this would
> become something like:
> if (ops->set_voltage_time) {
> return ops->set_voltage_time(...);
> } else if (!ops->set_voltage_time_sel) {
> return _regulator_set_voltage_time(..);
> }
I suspect you'll end up with more refactoring than that around
_set_voltage_time() and this'll be inside that function but I've lost
context here so ICBW.
signature.asc
Description: PGP signature
Re: [PATCH v4 1/4] regulator: Add set_voltage_time op
Hi Mark,
thanks for your review, please find some comments below.
El Mon, Sep 12, 2016 at 07:32:30PM +0100 Mark Brown ha dit:
> On Tue, Sep 06, 2016 at 12:03:15PM -0700, Matthias Kaehlcke wrote:
>
> Whatever you're using to send these is not threading things as expected
> and is adding a random HTML segment to the end of the e-mails - you
> probably want to look at this. If you're trying to use gmail via the
> web interface you want to avoid that, it's got a tendency to mangle
> things.
Sorry about that, I'll try to use git send-email in the future to avoid
this kind of things.
> > - /* Call set_voltage_time_sel if successfully obtained old_selector */
> > - if (ret == 0 && !rdev->constraints->ramp_disable && old_selector >= 0
> > - && old_selector != selector) {
> > + if (ret != 0 || rdev->constraints->ramp_disable)
> > + goto no_delay;
>
> You probably want to do the refactoring for splitting out decisions
> about old_selector separately, it'll make the diff clearer.
The old_selector conditions could be moved into the "else if
(rdev->desc->ops->set_voltage_sel)" branch above, is that you mean?
> > - delay = rdev->desc->ops->set_voltage_time_sel(rdev,
> > - old_selector, selector);
>
> > + delay = rdev->desc->ops->set_voltage_time_sel(
> > + rdev, old_selector, selector);
>
> Coding style - there's no need to put the rdev on the new line and the
> arguments should be more indented. Look at how the original was
> indented...
ok
> > + /* Insert any necessary delays */
> > + if (delay >= 1000) {
> > + mdelay(delay / 1000);
> > + udelay(delay % 1000);
> > + } else if (delay) {
> > + udelay(delay);
> > + }
> > +
> > +no_delay:
>
> Why were the gotos there?
Not sure how to interpret your question. Would you prefer no to use
gotos, should the notification be skipped in case the voltage is not
changed, do you expect a comment, ...?
> > @@ -2993,54 +3005,58 @@ int regulator_set_voltage_time(struct regulator
> > *regulator,
> > {
> > struct regulator_dev *rdev = regulator->rdev;
> > const struct regulator_ops *ops = rdev->desc->ops;
> > - int old_sel = -1;
> > - int new_sel = -1;
> > - int voltage;
> > - int i;
> >
> > - /* Currently requires operations to do this */
> > - if (!ops->list_voltage || !ops->set_voltage_time_sel
> > - || !rdev->desc->n_voltages)
> > - return -EINVAL;
> > + if (ops->set_voltage_time) {
> > + return ops->set_voltage_time(rdev, old_uV, new_uV);
> > + } else if (ops->set_voltage_time_sel) {
> > + int old_sel = -1;
> > + int new_sel = -1;
> > + int voltage;
> > + int i;
> >
> > - for (i = 0; i < rdev->desc->n_voltages; i++) {
> > - /* We only look for exact voltage matches here */
> > - voltage = regulator_list_voltage(regulator, i);
>
> The diff and I expect the resulting code would be a lot clearer if we
> just left most of the function indented as it is and simply directly
> returned set_voltage_time(). Which is what we do anyway so no need to
> reindent the rest of the code.
Ok, with your comment below on a default implementation this would
become something like:
if (ops->set_voltage_time) {
return ops->set_voltage_time(...);
} else if (!ops->set_voltage_time_sel) {
return _regulator_set_voltage_time(..);
}
// previous code
It will certainly make the diff clearer, for the resulting code my
preference would be to avoid the negative condition on
ops->set_voltage_time_sel to enter the default case, but that's a
minor question.
> > +int regulator_set_voltage_time_op(struct regulator_dev *rdev,
> > + int old_uV, int new_uV)
> > {
> > unsigned int ramp_delay = 0;
> > - int old_volt, new_volt;
> >
> > if (rdev->constraints->ramp_delay)
> > ramp_delay = rdev->constraints->ramp_delay;
> > @@ -3052,6 +3068,28 @@ int regulator_set_voltage_time_sel(struct
> > regulator_dev *rdev,
> > return 0;
> > }
> >
> > + return DIV_ROUND_UP(abs(new_uV - old_uV), ramp_delay);
> > +}
> > +EXPORT_SYMBOL_GPL(regulator_set_voltage_time_op);
>
> This is getting very messy. Having the handling of the ramp delay DT
> properties in the operation that the driver in theory implements is
> making things harder than they should be (and we seem to have some
> broken drivers that don't do one or both of the ramp delays). I'm not
> sure this series is the place to fully fix that but it'd be good to
> start that refactoring by not requiring the op be set and instead just
> doing this implementation by default. That way there's less stuff to
> clean up later on.
Having this as default implementation sounds good. Thanks for the suggestion!
Matthias
Re: [PATCH v4 1/4] regulator: Add set_voltage_time op
On Tue, Sep 06, 2016 at 12:03:15PM -0700, Matthias Kaehlcke wrote:
Whatever you're using to send these is not threading things as expected
and is adding a random HTML segment to the end of the e-mails - you
probably want to look at this. If you're trying to use gmail via the
web interface you want to avoid that, it's got a tendency to mangle
things.
> - /* Call set_voltage_time_sel if successfully obtained old_selector */
> - if (ret == 0 && !rdev->constraints->ramp_disable && old_selector >= 0
> - && old_selector != selector) {
> + if (ret != 0 || rdev->constraints->ramp_disable)
> + goto no_delay;
You probably want to do the refactoring for splitting out decisions
about old_selector separately, it'll make the diff clearer.
> - delay = rdev->desc->ops->set_voltage_time_sel(rdev,
> - old_selector, selector);
> + delay = rdev->desc->ops->set_voltage_time_sel(
> + rdev, old_selector, selector);
Coding style - there's no need to put the rdev on the new line and the
arguments should be more indented. Look at how the original was
indented...
> + /* Insert any necessary delays */
> + if (delay >= 1000) {
> + mdelay(delay / 1000);
> + udelay(delay % 1000);
> + } else if (delay) {
> + udelay(delay);
> + }
> +
> +no_delay:
Why were the gotos there?
> @@ -2993,54 +3005,58 @@ int regulator_set_voltage_time(struct regulator
> *regulator,
> {
> struct regulator_dev *rdev = regulator->rdev;
> const struct regulator_ops *ops = rdev->desc->ops;
> - int old_sel = -1;
> - int new_sel = -1;
> - int voltage;
> - int i;
>
> - /* Currently requires operations to do this */
> - if (!ops->list_voltage || !ops->set_voltage_time_sel
> - || !rdev->desc->n_voltages)
> - return -EINVAL;
> + if (ops->set_voltage_time) {
> + return ops->set_voltage_time(rdev, old_uV, new_uV);
> + } else if (ops->set_voltage_time_sel) {
> + int old_sel = -1;
> + int new_sel = -1;
> + int voltage;
> + int i;
>
> - for (i = 0; i < rdev->desc->n_voltages; i++) {
> - /* We only look for exact voltage matches here */
> - voltage = regulator_list_voltage(regulator, i);
The diff and I expect the resulting code would be a lot clearer if we
just left most of the function indented as it is and simply directly
returned set_voltage_time(). Which is what we do anyway so no need to
reindent the rest of the code.
> +int regulator_set_voltage_time_op(struct regulator_dev *rdev,
> + int old_uV, int new_uV)
> {
> unsigned int ramp_delay = 0;
> - int old_volt, new_volt;
>
> if (rdev->constraints->ramp_delay)
> ramp_delay = rdev->constraints->ramp_delay;
> @@ -3052,6 +3068,28 @@ int regulator_set_voltage_time_sel(struct
> regulator_dev *rdev,
> return 0;
> }
>
> + return DIV_ROUND_UP(abs(new_uV - old_uV), ramp_delay);
> +}
> +EXPORT_SYMBOL_GPL(regulator_set_voltage_time_op);
This is getting very messy. Having the handling of the ramp delay DT
properties in the operation that the driver in theory implements is
making things harder than they should be (and we seem to have some
broken drivers that don't do one or both of the ramp delays). I'm not
sure this series is the place to fully fix that but it'd be good to
start that refactoring by not requiring the op be set and instead just
doing this implementation by default. That way there's less stuff to
clean up later on.
signature.asc
Description: PGP signature
Re: [PATCH v4 1/4] regulator: Add set_voltage_time op
On Tue, Sep 06, 2016 at 11:40:54PM +0100, Mark Brown wrote: > On Tue, Sep 06, 2016 at 02:01:25PM -0700, Matthias Kaehlcke wrote: > > The new op is analogous to set_voltage_time_sel. It can be used by > > regulators that don't have a table of discrete voltages. The function > I've only got patch 1 in this series, what's going on here? Actually it turns out I have at least three copies of this, one copy of what's hopefully the reset of the series and none of them are threaded together :( You probably want to take a look at your patch sending setup... signature.asc Description: PGP signature
Re: [PATCH v4 1/4] regulator: Add set_voltage_time op
On Tue, Sep 06, 2016 at 02:01:25PM -0700, Matthias Kaehlcke wrote: > The new op is analogous to set_voltage_time_sel. It can be used by > regulators that don't have a table of discrete voltages. The function I've only got patch 1 in this series, what's going on here? signature.asc Description: PGP signature
