public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@saeurebad.de>
To: Alexey Starikovskiy <astarikovskiy@suse.de>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Johannes Weiner <hannes-kernel@saeurebad.de>,
	"Michael (rabenkind) Brandstetter" <listen@selfservix.org>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: 2.6.24-rc1: OOPS at  acpi_battery_update
Date: Thu, 8 Nov 2007 17:46:06 +0100	[thread overview]
Message-ID: <20071108164606.GB12231@cataract> (raw)
In-Reply-To: <47333549.90505@suse.de>

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

  reply	other threads:[~2007-11-08 16:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 10:11 2.6.24-rc1: OOPS at acpi_battery_update Romano Giannetti
2007-11-01 23:14 ` Andrew Morton
2007-11-02 16:08   ` Rafael J. Wysocki
2007-11-04  9:34     ` *SPAM* " Romano Giannetti
2007-11-04 13:17       ` Rafael J. Wysocki
2007-11-04 23:29         ` Michael (rabenkind) Brandstetter
2007-11-05  0:18           ` Rafael J. Wysocki
2007-11-08 15:53             ` Johannes Weiner
2007-11-08 16:16               ` Rafael J. Wysocki
2007-11-08 16:11                 ` Alexey Starikovskiy
2007-11-08 16:46                   ` Johannes Weiner [this message]
2007-11-08 16:35                 ` Alexey Starikovskiy
2007-11-08 16:58                   ` Johannes Weiner
2007-11-09  4:34                   ` Andrew Morton
2007-11-09  9:36                     ` Alexey Starikovskiy
2007-11-09  9:49                       ` Andrew Morton
2007-11-13  8:35                         ` Alexey Starikovskiy
2007-11-13  8:59                           ` Andrew Morton

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=20071108164606.GB12231@cataract \
    --to=hannes@saeurebad.de \
    --cc=astarikovskiy@suse.de \
    --cc=hannes-kernel@saeurebad.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=listen@selfservix.org \
    --cc=rjw@sisk.pl \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox