Re: [PATCH 3/3] power: supply: initial support for TWL6030/32
From: Andreas Kemnade
Date: Mon Sep 23 2024 - 12:30:10 EST
Am Wed, 18 Sep 2024 12:43:01 +0200
schrieb Krzysztof Kozlowski <krzk@xxxxxxxxxx>:
> On 18/09/2024 10:41, Andreas Kemnade wrote:
> > Add a driver for the charger in the TWL6030/32. For now it does not
> > report much in sysfs but parameters are set up for USB, charging is
> > enabled with the specified parameters. It stops charging when full
> > and also restarts charging.
> > This prevents ending up in a system setup where you run out of
> > battery although a charger is plugged in after precharge completed.
> >
> > Battery voltage behavior was checked via the GPADC.
> >
>
> Few stylistic comments below.
>
> > Signed-off-by: Andreas Kemnade <andreas@xxxxxxxxxxxx>
> > ---
> > drivers/power/supply/Kconfig | 10 +
> > drivers/power/supply/Makefile | 1 +
> > drivers/power/supply/twl6030_charger.c | 566
> > +++++++++++++++++++++++++ 3 files changed, 577 insertions(+)
> > create mode 100644 drivers/power/supply/twl6030_charger.c
> >
> > diff --git a/drivers/power/supply/Kconfig
> > b/drivers/power/supply/Kconfig index bcfa63fb9f1e2..9f2eef6787f7a
> > 100644 --- a/drivers/power/supply/Kconfig
> > +++ b/drivers/power/supply/Kconfig
> > @@ -493,6 +493,16 @@ config CHARGER_TWL4030
> > help
> > Say Y here to enable support for TWL4030 Battery Charge
> > Interface.
> > +config CHARGER_TWL6030
> > + tristate "OMAP TWL6030 BCI charger driver"
> > + depends on IIO && TWL4030_CORE
>
> || COMPILE_TEST, at least for TWL part
> (but please test first)
>
ERROR: modpost: "twl_i2c_write"
[drivers/power/supply/twl6030_charger.ko] undefined! ERROR: modpost:
"twl_i2c_read" [drivers/power/supply/twl6030_charger.ko] undefined!
>
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, twl_charger_of_match);
> > +
> > +static struct platform_driver twl6030_charger_driver = {
> > + .probe = twl6030_charger_probe,
> > + .driver = {
> > + .name = "twl6030_charger",
> > + .of_match_table =
> > of_match_ptr(twl_charger_of_match),
>
> I propose to drop of_match_ptr and maybe_unused, so this won't be
> restricted only to OF
>
so that more things get compile-tested without OF? But I see no reason
why .probe would be optimized away (and with it a lot more things) by
the compiler.
Regards,
Andreas