[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171204195524.GA25730@thinkpad>
Date: Mon, 4 Dec 2017 20:55:24 +0100
From: Ognjen Galic <smclt30p@...il.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Jonathan Corbet <corbet@....net>, Len Brown <lenb@...nel.org>,
Darren Hart <dvhart@...radead.org>,
Andy Shevchenko <andy@...radead.org>,
Henrique de Moraes Holschuh <ibm-acpi@....eng.br>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
ibm-acpi-devel@...ts.sourceforge.net
Subject: Re: [PATCH v2] thinkpad_acpi: Support the battery wear control
On Mon, Dec 04, 2017 at 03:53:32PM +0100, Rafael J. Wysocki wrote:
> Not really.
>
> This is generic code, so no thinkpad_acpi-specific stuff in this file, please,
> even under #ifdefs.
>
I have some ideas, and I want your confirmation if that would be
acceptable.
Can I do this:
Expose a new API from battery.c for platform specific hooks:
struct battery_hook {
int (*add_battery)(struct acpi_battery* battery);
int (*remove_battery)(struct acpi_battery *battery);
};
battery_hook_register(struct battery_hook *hook)
battery_hook_unregister(struct battery_hook *hook)
When that hook is invoked from some other module, battery.c
calls the add_battery method for each battery that is added and
remove_battery for each battery that is removed.
battery.c would keep a list of the battery_hook structs and invoke
the add_battery and remove_battery methods as batteries get added
and removed.
With this API, we can add more hooks for battery features in
the future, not just the ThinkPad hooks.
I hope you like the proposal :)
Powered by blists - more mailing lists