On Mon, 2007-02-26 at 17:27 +0100, Jean Delvare wrote:
Hi Henrique,
On Sat, 24 Feb 2007 16:20:24 -0200, Henrique de Moraes Holschuh wrote:
I am working on a conversion of ibm-acpi to sysfs, and in the process I am
trying to do away with every non-generic interface I can. At least two
On Wednesday, 28 February 2007 02:27, Mitch Davis wrote:
On 2/28/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Wednesday, 28 February 2007 01:04, Mitch Davis wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7988
In the bug, Rafael J. Wysocki suggested:
Can you try
(ibm-acpi-devel removed from cc, subject changed)
On Wed, 28 Feb 2007, Zhang Rui wrote:
I'm converting these two modules to sysfs. I think thermal has too
much ACPI specific information and is not that easy to have a generic
interface.
It is not easy. In fact, it could be quite complicated.
On Mon, 2007-02-26 at 09:34 -0500, Dmitry Torokhov wrote:
Hi Thomas,
On 2/26/07, Thomas Renninger [EMAIL PROTECTED] wrote:
On Thu, 2007-02-22 at 10:02 -0500, Dmitry Torokhov wrote:
Hope this makes sense (I must admit it makes little sense to me ;) ).
Same for me at the beginning.
On Mon, 26 Feb 2007, Jean Delvare wrote:
I was going to place all fan attributes in a sysfs group (subdirectory)
named fan, and all thermal attributes in a sysfs group named thermal. Is
that acceptable?
No, it's not, as it wouldn't be compatible with what all the other
drivers do and
Hi,
Here is the final set of EC init patches.
Renamed ec_ecdt into boot_ec, hope that's ok...
Regards,
Alex.
From nobody Thu Mar 1 01:31:38 2007
Subject: [PATCH 1/9] ACPI: EC: Make EC to initialize first in ACPI
To: Alexey Starikovskiy [EMAIL PROTECTED]
Date: Thu, 01 Mar 2007 01:31:38 +0300
[EMAIL PROTECTED] wrote:
Corey,
Here is the patch (RHEL5 base code) I've been testing that detects the ACPI
namespace object.
The IPI0001 device doesn't contain the register spacing directly; it has a
_CRS resource object that
(for KCS) has two I/O port entries. I save the first port
The reason for the acpi_bus_register/unregister is to get the handle of the
IPMI ACPI object. There isn't a way to get the device handle otherwise. Once
it gets the handle it doesn't need the ACPI device anymore. It's not the best
solution, but the current way that the SI driver initializes
On Wednesday 28 February 2007 15:05, [EMAIL PROTECTED] wrote:
The reason for the acpi_bus_register/unregister is to get the handle
of the IPMI ACPI object. There isn't a way to get the device handle
otherwise. Once it gets the handle it doesn't need the ACPI device
anymore.
Well, but in a
Bjorn Helgaas wrote:
On Wednesday 28 February 2007 15:05, [EMAIL PROTECTED] wrote:
The reason for the acpi_bus_register/unregister is to get the handle
of the IPMI ACPI object. There isn't a way to get the device handle
otherwise. Once it gets the handle it doesn't need the ACPI device
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Handled-By : Ingo Molnar [EMAIL PROTECTED]
Status : unknown
Just reproduced this in -rc2.
Another thing I noticed:
with 2.6.20, pressing
On Wed, 2007-02-28 at 23:13 +0200, Michael S. Tsirkin wrote:
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Handled-By : Ingo Molnar [EMAIL PROTECTED]
Status : unknown
Just
Hi!
Well I had an idea after looking at k8temp -- why not make it default to
doing only reads from the sensor? You'd only get information from whatever
core/sensor combination that ACPI had last used, but it would be safe.
ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
Quoting Thomas Gleixner [EMAIL PROTECTED]:
Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)
On Wed, 2007-02-28 at 23:13 +0200, Michael S. Tsirkin wrote:
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S.
This exception appears to be originating somewhere in the EC driver:
ACPI Exception (evregion-0420): AE_NOT_FOUND, Returned by Handler for
[EmbeddedControl] [20070126]
-Original Message-
From: [EMAIL PROTECTED] [mailto:linux-acpi-
[EMAIL PROTECTED] On Behalf Of Meelis Roos
Sent:
To provide compatibilty with SN kernels that do and do not
have ACPI IO support, the SN PROM must build different
versions of some ACPI tables based on which kernel is booting.
As such, the tables may have to change at kernel boot time.
By default, prior to kernel boot, the PROM builds an empty
Arkadiusz,
Could try the attached patch to see if it solves the problem?
If not, please send the output of acpidump command and log.
Regards.
Konstantin.
-Original Message-
From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 25, 2007 8:53 PM
To: Linus Torvalds; Andrew
On 3/1/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
On 2.6.21-rc2, after resume (when the box is accessible from network),
pressing Fn/F4 again does not seem to have any effect.
I have the same problem on my
On Wed, 28 Feb 2007 17:31:51 +0800, Zhang Rui wrote:
The standard ACPI fan and thermal modules?
I'm converting these two modules to sysfs. I think thermal has too
much ACPI specific information and is not that easy to have a generic
interface.
Could you give some more detailed descriptions
On Wed, 28 Feb 2007 11:38:36 -0300, Henrique de Moraes Holschuh wrote:
Ok, I have fan*_* and temp*_input hanging directly from the device (no
groups). However, that device has a lot of other stuff that is not even
remotely accounted for in hwmon, such as control of video outputs and
hotkeys,
so will the 1st acpi_table_init() always fail -- even
on future machines?
-Len
On Wednesday 28 February 2007 18:47, John Keller wrote:
To provide compatibilty with SN kernels that do and do not
have ACPI IO support, the SN PROM must build different
versions of some ACPI tables based on which
21 matches
Mail list logo
