Bjorn's response to my statements is correct.
The idea is that _OSI tells the platform that the OS supports the
loading of a module device so the platform firmware can declare devices
under it instead of somewhere else. i.e. the platform can assume that
the devices will be loaded.
I view it as a A
On Tue, Apr 25, 2006 at 02:50:57PM +0800, Yu, Luming wrote:
> - for (i = 0; i < 16; i++)
> + for (i = 15; i >= 0 ; i--)
We certainly need to do /something/ here, but I'm not sure this is it.
Adam Belay has code to limit PCI state restoration to the PCI-specified
registers, with the idea
On Tue, 2006-04-25 at 11:48 +0100, Matthew Garrett wrote:
> On Tue, Apr 25, 2006 at 02:50:57PM +0800, Yu, Luming wrote:
>
> > - for (i = 0; i < 16; i++)
> > + for (i = 15; i >= 0 ; i--)
>
> We certainly need to do /something/ here, but I'm not sure this is it.
> Adam Belay has code to limit
On Tue, Apr 25, 2006 at 12:51:01PM +0200, Arjan van de Ven wrote:
> it has a second drawback: it assumes all devices HAVE a driver, which
> isn't normally the case...
Yeah, I guess there's a call for keeping a pci_save_entire_state type
call and getting pci_device_suspend to use that in the no-d
Hi,
I got this week-end the problem described by the thread "how to back
from suspend without shutdown". I've hacked a little patch for solving
this issue. I've tested with the 2.6.17rc1 on two platforms and it's
working.
Regards,
Arnaud Patard
Suppress POWER_BUTTON event on S3 resume.
Signed-
>> >> > There are keyboards with power/sleep buttons. It makes
>> >sense they have
>> >> > the same behavior than ACPI buttons.
>> >> Agree, make them behave like ACPI buttons -- remove them
>> >from input stream, as they do not belong there...
>> >
>> >What if there is no ACPI? What if I want to r
Per Andi Kleen's request, I have made slight changes to the patch I
submitted last week. Look for the "snip" further down if you don't
want to re-read the original post. Thanks!
--- Begin original post ---
Hello!
I'm working on an x86_64 platfrom, where I've hit a probl
I would appreciate it if someone would send me both the binary DSDT or
acpixtract output and the disassembled file.
Thanks,
Bob
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-acpi-
> [EMAIL PROTECTED] On Behalf Of Brown, Len
> Sent: Monday, April 24, 2006 2:33 PM
> To: Ivá
>On Tue, 2006-04-25 at 11:48 +0100, Matthew Garrett wrote:
>> On Tue, Apr 25, 2006 at 02:50:57PM +0800, Yu, Luming wrote:
>>
>> > - for (i = 0; i < 16; i++)
>> > + for (i = 15; i >= 0 ; i--)
>>
>> We certainly need to do /something/ here, but I'm not sure
>> this is it.
>> Adam Belay has cod
I'd rather see the original irq-renaming patch
and its subsequent multiple via workaround patches
reverted than to further complicate what is becoming
a fragile mess.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More maj
This looks like a case where there are one or more SSDTs and the disassembler
has a difficult time deciphering method calls from the DSDT to the SSDT(s).
This is a feature (along with the automatic generation of External()
statements) that is on the TBD list for the disassembler.
Parens help in
Quoting "Brown, Len" <[EMAIL PROTECTED]>:
On Tue, 2006-04-25 at 11:48 +0100, Matthew Garrett wrote:
On Tue, Apr 25, 2006 at 02:50:57PM +0800, Yu, Luming wrote:
> - for (i = 0; i < 16; i++)
> + for (i = 15; i >= 0 ; i--)
We certainly need to do /something/ here, but I'm not sure
this is it
12 matches
Mail list logo
