linux-kernel - Re: [PATCH v5 05/10] power: supply: rt5033_charger: Add RT5033 charger device 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] [day] [month] [year] [list]

Message-ID: <20230514225108.pkn2zufrfgic7r4c@mercury.elektranox.org>
Date:   Mon, 15 May 2023 00:51:08 +0200
From:   Sebastian Reichel <sebastian.reichel@...labora.com>
To:     Jakob Hauser <jahau@...ketmail.com>
Cc:     Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Lee Jones <lee@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Beomho Seo <beomho.seo@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Stephan Gerhold <stephan@...hold.net>,
        Raymond Hackley <raymondhackley@...tonmail.com>,
        Pavel Machek <pavel@....cz>, Axel Lin <axel.lin@...ics.com>,
        ChiYuan Huang <cy_huang@...htek.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Henrik Grimler <henrik@...mler.se>, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        phone-devel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH v5 05/10] power: supply: rt5033_charger: Add RT5033
 charger device driver

Hi,

On Sun, May 14, 2023 at 07:03:03PM +0200, Jakob Hauser wrote:
> Hi Christophe, Hi all,
> 
> On 14.05.23 16:31, Christophe JAILLET wrote:
> > Le 14/05/2023 à 14:31, Jakob Hauser a écrit :
> 
> ...
> 
> > > +static int rt5033_charger_probe(struct platform_device *pdev)
> > > +{
> > > +    struct rt5033_charger *charger;
> > > +    struct power_supply_config psy_cfg = {};
> > > +    int ret;
> > > +
> > > +    charger = devm_kzalloc(&pdev->dev, sizeof(*charger), GFP_KERNEL);
> > > +    if (!charger)
> > > +        return -ENOMEM;
> > > +
> > > +    platform_set_drvdata(pdev, charger);
> > > +    charger->dev = &pdev->dev;
> > > +    charger->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> > > +
> > > +    psy_cfg.of_node = pdev->dev.of_node;
> > > +    psy_cfg.drv_data = charger;
> > > +
> > > +    charger->psy = devm_power_supply_register(&pdev->dev,
> > > +                          &rt5033_charger_desc,
> > > +                          &psy_cfg);
> > > +    if (IS_ERR(charger->psy))
> > > +        return dev_err_probe(&pdev->dev, PTR_ERR(charger->psy),
> > > +                     "Failed to register power supply\n");
> > > +
> > > +    charger->chg = rt5033_charger_dt_init(charger);
> > > +    if (IS_ERR_OR_NULL(charger->chg))
> > 
> > Hi,
> > 
> > Nit: charger->chg can't be NULL.
> > 
> > > +        return -ENODEV;
> > 
> > Why bother returning specific error code in rt5033_charger_dt_init() if
> > they are eaten here.
> > 
> > return PTR_ERR(charger->chg)?
> > 
> 
> Thanks for the heads-up.
> 
> ...
> 
> Writing towards the list:
> 
> The way it is done in the current patchset is taken from the original
> patchset of March 2015 [2]. I kept the original as far as possible.
> 
> By now I'm not happy with the way of initializing "struct
> rt5033_charger_data". I realized this in the course of the review. As I
> didn't want to disturb the review with this, I had planned a small clean-up
> patch after this review is finished.
> 
> The cause of the complicated handling of "struct rt5033_charger_data" lies
> inside of the "struct rt5033_charger". There the "struct
> rt5033_charger_data" is initialized as pointer *chg.
> 
> The clean-up would be:
> 
>  - Inside of "struct rt5033_charger" change the
>    "struct rt5033_charger_data" to non-pointer "chg". It is then
>    initialized right away.
> 
>       struct rt5033_charger_data      chg;
> 
>  - Change function rt5033_charger_dt_init() from type
>    "struct rt5033_charger_data" to type "int".
> 
>       static int rt5033_charger_dt_init(struct rt5033_charger *charger)
> 
>  - In the probe function, call the function rt5033_charger_dt_init() in
>    the same way like e.g. the following rt5033_charger_reg_init():
> 
>       ret = rt5033_charger_dt_init(charger);
>               if (ret)
>                       return ret;
> 
>  - Within function rt5033_charger_dt_init() and all other functions
>    using the charger data, get the address of the already-initialized
>    struct &charger->chg.
> 
>       struct rt5033_charger_data *chg = &charger->chg;
> 
> This would also solve the issue reported by Christophe because the errors
> inside function rt5033_charger_dt_init() would be passed to the probe
> function by the "ret =" and being returned there with "return ret".
> 
> I'm not sure how to handle this now. I would prefer to get the review of
> this patchset finished and send a clean-up patch afterwards.
> 
> [2] https://lore.kernel.org/lkml/1425864191-4121-1-git-send-email-beomho.seo@samsung.com/T/#u

Sounds sensible, until then please use 'return PTR_ERR(charger->chg)'
as suggested by Christophe. With this fixed:

Acked-by: Sebastian Reichel <sebastian.reichel@...labora.com>

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)