linux-kernel - Re: [PATCH 08/13] regulator: max77650: add regulator support

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: <CAMpxmJX8OmnDtOhQjWi9edX-4pHu1daKiDkRdNAVw-PZsz9UXA@mail.gmail.com>
Date:   Fri, 18 Jan 2019 19:13:38 +0100
From:   Bartosz Golaszewski <bgolaszewski@...libre.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Lee Jones <lee.jones@...aro.org>,
        Sebastian Reichel <sre@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-gpio <linux-gpio@...r.kernel.org>,
        linux-devicetree <devicetree@...r.kernel.org>,
        linux-input@...r.kernel.org, linux-leds@...r.kernel.org,
        linux-pm <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 08/13] regulator: max77650: add regulator support

pt., 18 sty 2019 o 19:01 Mark Brown <broonie@...nel.org> napisał(a):
>
> On Fri, Jan 18, 2019 at 02:42:39PM +0100, Bartosz Golaszewski wrote:
>
> > Add regulator support for max77650. We support all four variants of this
> > PMIC including non-linear voltage table for max77651 SBB1 rail.
>
> Looks good, the ramping stuff might be a candidate for core (TBH I was
> sure we'd got that implemented already but we don't seem to) but that
> can be done later and the more complex one with non-linear steps does
> feel like it might have to stay in the driver anyway.
>
> A couple of small nits:
>
> > +++ b/drivers/regulator/max77650-regulator.c
> > @@ -0,0 +1,537 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 BayLibre SAS
> > + * Author: Bartosz Golaszewski <bgolaszewski@...libre.com>
>
> Please make the entire header C++ style so it looks more intentional.
>

Seems like there are more files in the kernel source using the mixed
comment style for the SPDX identifier and I also prefer it over C++
only. Would you mind if it stayed that way?

> > +             for_each_child_of_node(dev->of_node, child) {
> > +                     if (!of_node_name_eq(child, rdesc->desc.name))
> > +                             continue;
> > +
> > +                     init_data = of_get_regulator_init_data(dev, child,
> > +                                                            &rdesc->desc);
> > +                     if (!init_data)
> > +                             return -ENOMEM;
> > +
> > +                     config.of_node = child;
> > +                     config.init_data = init_data;
> > +             }
>
> You don't need to do this, the core will do it for you (it will actually
> still do it even with the above, it'll only fall back to using
> config->init_data if it's own lookup fails).

I added this loop specifically because the core would not pick up the
init data from DT. What did I miss (some specific variable to assign)?
I just noticed some other drivers do the same and thought it's the
right thing to do.

Thanks,
Bart