lkml.org 
[lkml]   [2020]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 4/5] regulator: qcom: Add labibb driver
On Tue, Jun 02, 2020 at 05:40:45PM +0530, Sumit Semwal wrote:
> On Tue, 2 Jun 2020 at 17:02, Mark Brown <broonie@kernel.org> wrote:
> > On Tue, Jun 02, 2020 at 03:39:23PM +0530, Sumit Semwal wrote:

> > This should be a get_status() callback...

> From my (limited) understanding of downstream code, it seemed like for
> this set of regulators, the 'enabled' check is done via the
> 'REG_LABIBB_STATUS1 reg; for some reason, not via the same enable_reg
> / enable_mask ones. That's why I used it as is_enabled() callback.
> I will try and check with the QC folks to clarify this point about
> their hardware.

The way this is functioning at the minute the downstream code is just
buggy.

> > ...is_enabled() should just be regulator_is_enabled_regmap() and these
> > functions should just be removed entirely, you can use the regmap
> > operations directly as the ops without the wrapper.

> The 2 wrappers are a precursor to the next patch, where we keep track
> of regulator's enable status to check during SC handling.

Add the functions when they're useful, not before. TBH if the register
is write only you're probably better off adding a register cache.

> > > + match = of_match_device(qcom_labibb_match, &pdev->dev);
> > > + if (!match)
> > > + return -ENODEV;
> > > +
> > > + for (reg_data = match->data; reg_data->name; reg_data++) {
> > > + child = of_get_child_by_name(pdev->dev.of_node, reg_data->name);
> > > +
> > > + if (WARN_ON(child == NULL))
> > > + return -EINVAL;
> >
> > This feels like the DT bindings are confused - why do we need to search
> > like this?

> The WARN_ON? This was suggested by Bjorn to catch the case where the
> DT binding for a PMIC instantiates only one of the regulators.

No, this whole loop - why this whole match and get child stuff?
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2020-06-02 14:26    [W:0.070 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site