Messages in this thread | | | Date | Sun, 14 May 2023 19:03:03 +0200 | Subject | Re: [PATCH v5 05/10] power: supply: rt5033_charger: Add RT5033 charger device driver | From | Jakob Hauser <> |
| |
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
Kind regards, Jakob
| |