Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190726123058.22915-1-hslester96@gmail.com> <20190727125749.63297c28@archlinux>
 <20190728083141.GA14194@onstation.org> <CANhBUQ3QiV1mPD6p+AROv6YnK+1CB5voVAHKbmzueUWc7P6vcQ@mail.gmail.com>
 <20190729080307.GA360@onstation.org> <20190729120802.000025e8@huawei.com>
In-Reply-To: <20190729120802.000025e8@huawei.com>
From:   Chuhong Yuan <hslester96@gmail.com>
Date:   Mon, 29 Jul 2019 21:02:09 +0800
Message-ID: <CANhBUQ0eBs5ExByztvsKf9eRbKKLXkLkhduQ59VqcGTU0kDOvQ@mail.gmail.com>
Subject: Re: [PATCH] iio: tsl2772: Use device-managed API
To:     Jonathan Cameron <jonathan.cameron@huawei.com>
Cc:     Brian Masney <masneyb@onstation.org>,
        Jonathan Cameron <jic23@kernel.org>, linux-iio@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Jonathan Cameron <jonathan.cameron@huawei.com> =E4=BA=8E2019=E5=B9=B47=E6=
=9C=8829=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=887:09=E5=86=99=E9=81=
=93=EF=BC=9A
>
> On Mon, 29 Jul 2019 04:03:07 -0400
> Brian Masney <masneyb@onstation.org> wrote:
>
> > On Mon, Jul 29, 2019 at 11:03:00AM +0800, Chuhong Yuan wrote:
> > > Brian Masney <masneyb@onstation.org> =E4=BA=8E2019=E5=B9=B47=E6=9C=88=
28=E6=97=A5=E5=91=A8=E6=97=A5 =E4=B8=8B=E5=8D=884:31=E5=86=99=E9=81=93=EF=
=BC=9A
> > > > devm_add_action() could be used in the probe function to schedule t=
he call
> > > > to tsl2772_chip_off(). That would eliminate the need for
> > > > tsl2772_remove(). See tsl2772_disable_regulators_action() for an ex=
ample in
> > > > that driver.
> > > >
> > >
> > > I find that we can use devm_add_action_or_reset() for
> > > tsl2772_disable_regulators_action() to eliminate the fault handling c=
ode.
> > >
> > > I am not sure whether devm_add_action() can be used for
> > > tsl2772_chip_off() because it returns an integer, not void.
> > > And the return value is used in several functions.
> >
> > I would add a wrapper function (tsl2772_chip_off_action?) with the
> > expected declaration that calls tsl2772_chip_off().
> >
> > > > Chuhong: Another potential cleanup to shrink the size of this drive=
r is
> > > > to move it over to the regulator_bulk_() API. I didn't realize that=
 API
> > > > existed at the time I introduced the regulator support. If you're
> > > > interested in taking on that cleanup as well, I can test those chan=
ges
> > > > for you if you don't have the hardware.
> > > >
> > > > Brian
> > > >
> > >
> > > Does that mean merging vdd_supply and vddio_supply to an array of
> > > regulator_bulk_data and utilize regulator_bulk_() API to operate them
> > > together?
> >
> > Yes.
> >
> > > I have an additional question that I find regulator_disable() is used=
 in the
> > > end of many .remove functions of drivers, which hinders us to use dev=
m
> > > functions.
> > > One example is drivers/iio/light/gp2ap020a00f.c.
> > > Is there any solution to this problem?
> >
> > There are devm_regulator_*() variants of the regulator API available
> > that you can use. Lots of other APIs in the kernel have devm variants
> > to simply drivers.
> I don't think there are any devm_ versions of regulator disable.
>
> IIRC the argument made when this last came up was that it was rarely corr=
ect
> to be as course grained as a lot of IIO drivers are.   We should probably
> do runtime pm and turn these regulators off a lot more frequently.
>
> The reality is that it is an optimization that doesn't get done in
> IIO drivers that often as we mostly just want them to work and many
> usecases aren't actually power constrained,
>
> So we end up doing a lot of devm_add_action_or_reset to power down the
> regulators.
>

I think I can add devm_ versions of regulator_enable and disable.

Chuhong

> Jonathan
> >
> > Brian
>
>