linux-kernel - Re: [PATCH v4 4/5] regulator: qcom: Add labibb driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAO_48GGgNUGosN2PiL=U5JkR3Bh5wNK3N4xYYML1UwmdfDPRww@mail.gmail.com>
Date:   Tue, 2 Jun 2020 17:40:45 +0530
From:   Sumit Semwal <sumit.semwal@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     agross@...nel.org, Bjorn Andersson <bjorn.andersson@...aro.org>,
        lgirdwood@...il.com, robh+dt@...nel.org,
        Nisha Kumari <nishakumari@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org, kgunda@...eaurora.org,
        Rajendra Nayak <rnayak@...eaurora.org>
Subject: Re: [PATCH v4 4/5] regulator: qcom: Add labibb driver

Hi Mark,

Thank you very much for reviewing.


On Tue, 2 Jun 2020 at 17:02, Mark Brown <broonie@...nel.org> wrote:
>
> On Tue, Jun 02, 2020 at 03:39:23PM +0530, Sumit Semwal wrote:
>
> > +static int qcom_labibb_regulator_is_enabled(struct regulator_dev *rdev)
> > +{
> > +     int ret;
> > +     unsigned int val;
> > +     struct labibb_regulator *reg = rdev_get_drvdata(rdev);
> > +
> > +     ret = regmap_read(reg->regmap, reg->base + REG_LABIBB_STATUS1, &val);
> > +     if (ret < 0) {
> > +             dev_err(reg->dev, "Read register failed ret = %d\n", ret);
> > +             return ret;
> > +     }
> > +     return !!(val & LABIBB_STATUS1_VREG_OK_BIT);
> > +}
>
> 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.

> > +static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
> > +{
> > +     return regulator_enable_regmap(rdev);
> > +}
> > +
> > +static int qcom_labibb_regulator_disable(struct regulator_dev *rdev)
> > +{
> > +     return regulator_disable_regmap(rdev);
> > +}
>
> ...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.
>
> > +     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.
>
> > +             dev_info(dev, "Registering %s regulator\n", child->full_name);
>
> This is noise, remove it.  The regulator framework will announce new
> regulators anyway.
Agreed. will remove in the next iteration.

Best,
Sumit.