From: Szilard Fabian <szfabian@bluemarch.art>
To: Armin Wolf <W_Armin@gmx.de>
Cc: hdegoede@redhat.com, ilpo.jarvinen@linux.intel.com,
jwoithe@just42.net, linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org
Subject: Re: [RFC PATCH v2] platform/x86/fujitsu-laptop: Add battery charge control support
Date: Sat, 03 Feb 2024 00:17:58 +0000 [thread overview]
Message-ID: <Zb2GMCSIz1MuWpQZ@N> (raw)
In-Reply-To: <fabf391c-933c-4a7b-a23c-d361ad3d7cc0@gmx.de>
Hello,
On Tue, Jan 30, 2024 at 03:02:09AM +0100, Armin Wolf wrote:
> Am 29.01.24 um 19:00 schrieb Szilard Fabian:
> > +
> > + return sprintf(buf, "%d\n", status);
> > +}
> > +
> > +static DEVICE_ATTR_RW(charge_control_end_threshold);
> > +
> > +/* ACPI battery hook */
> > +
> > +static int fujitsu_battery_add(struct power_supply *battery,
> > + struct acpi_battery_hook *hook)
> > +{
> > + /* Check if there is an existing FUJ02E3 ACPI device. */
> > + if (fext == NULL)
> > + return -ENODEV;
>
> Can you put the struct acpi_battery_hook into the struct fujitsu_laptop
> and then use container_of() to retrieve the ACPI device from there?
> The dell-wmi-ddv driver does something similar.
>
> This would guarantee that the battery hook always accesses the correct ACPI device
> and you could drop this check.
>
> > +
> > + /*
> > + * Check if the S006 0x21 method exists by trying to get the current
> > + * battery charge limit.
> > + */
> > + int s006_cc_return;
> > + s006_cc_return = call_fext_func(fext, FUNC_S006_METHOD,
> > + CHARGE_CONTROL_RW, 0x21, 0x0);
> > + if (s006_cc_return == UNSUPPORTED_CMD)
> > + return -ENODEV;
>
> Maybe this check should be done once during probe?
What about the following scenario?
- Put a bool into the struct fujitsu_laptop to store information about the
machine's charge control ability.
- The S006 0x21 method check with `battery_hook_register` gets moved into
an 'init function'. In that 'init function' the bool gets set accordingly.
- `battery_hook_unregister` gets moved into an 'exit function', where the
bool gets read and when it's false nothing happens.
- `fext` check gets removed from `fujitsu_battery_add` because it's
redundant (more about that later).
- The 'init function' gets called in `acpi_fujitsu_laptop_add` and the 'exit
function' gets called in `acpi_fujitsu_laptop_remove`.
With that scenario the code could be a little bit clearer in my opinion.
And it is possible to drop the `fext` check because if the FUJ02E3 ACPI
device exists `fext` gets set in the `acpi_fujitsu_laptop_add` function with
an error check.
(And the `fujitsu_battery_add` `fext` check was already redundant because
`battery_hook_register` got called in `acpi_fujitsu_laptop_add`. `fext`
gets set in the same function, and there is an error check already.)
Thanks,
Szilard
next prev parent reply other threads:[~2024-02-03 0:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 16:36 [RFC PATCH] platform/x86/fujitsu-laptop: Add battery charge control support Szilard Fabian
2024-01-29 18:00 ` [RFC PATCH v2] " Szilard Fabian
2024-01-30 2:02 ` Armin Wolf
2024-02-03 0:17 ` Szilard Fabian [this message]
2024-02-05 17:07 ` Armin Wolf
2024-02-05 23:37 ` Jonathan Woithe
2024-02-07 2:32 ` [RFC PATCH v3] " Szilard Fabian
2024-02-07 8:57 ` Hans de Goede
2024-02-08 1:56 ` Szilard Fabian
2024-02-08 9:11 ` Hans de Goede
2024-02-15 11:34 ` Ilpo Järvinen
2024-02-15 20:12 ` Szilard Fabian
2024-02-16 9:27 ` Ilpo Järvinen
2024-02-15 20:31 ` [PATCH v4] " Szilard Fabian
2024-02-18 4:47 ` Jonathan Woithe
2024-02-19 12:06 ` Ilpo Järvinen
2024-02-27 10:18 ` Ilpo Järvinen
2024-02-27 12:04 ` Szilard Fabian
2024-02-27 12:05 ` [PATCH v5] " Szilard Fabian
2024-02-27 12:53 ` Ilpo Järvinen
2024-02-27 21:47 ` Jonathan Woithe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zb2GMCSIz1MuWpQZ@N \
--to=szfabian@bluemarch.art \
--cc=W_Armin@gmx.de \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jwoithe@just42.net \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.