[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071108164606.GB12231@cataract>
Date: Thu, 8 Nov 2007 17:46:06 +0100
From: Johannes Weiner <hannes@...urebad.de>
To: Alexey Starikovskiy <astarikovskiy@...e.de>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Johannes Weiner <hannes-kernel@...urebad.de>,
"Michael (rabenkind) Brandstetter" <listen@...fservix.org>,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: 2.6.24-rc1: OOPS at acpi_battery_update
Hi,
On Thu, Nov 08, 2007 at 07:11:53PM +0300, Alexey Starikovskiy wrote:
> Rafael J. Wysocki wrote:
> >On Thursday, 8 of November 2007, Johannes Weiner wrote:
> >>Hi,
> >>
> >>is there any reason, why acpi_battery_get_property() should call
> >>acpi_battery_update() at all?
> >
> >Alex?
> If someone wants to read stale values, he could comment out
> acpi_battery_update.
Please help me to understand:
When the battery is plugged in, the acpi_battery_notify() is called,
which in turn calls acpi_battery_update(). The latter ensures that the
sysfs files are created if not yet present.
When the battery is removed, acpi_battery_notify is called, which in
turn calls acpi_battery_update(). The latter ensures that the sysfs
files are removed if present.
During runtime - as far as I understood - no sysfs files have to be
created/removed but the saved battery state info becomes stale.
So, would it be enough to call acpi_battery_get_state() in
acpi_battery_get_property() instead of acpi_battery_update()?
If acpi_battery_get_state() does what I think it does, this would
ensure that the battery state is reread and updated when
acpi_battery_get_property() is called.
Hit me.
Hannes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists